Бизнес‑процессы часто моделируют как большие сквозные диаграммы, охватывающие несколько доменов. Это поначалу кажется логичным: ведь процесс должен «показать всё», что происходит, — заказ, оплату, доставку, обслуживание клиента, всё в одном потоке.
Но современные организации существуют в реальности, которую Барри О’Рейли описывает как гиперлиминальную (hyperliminal): программное обеспечение (упорядоченная, жесткая система) живет в социальной и экономической среде, которая сложна, непредсказуема и постоянно меняется. Процессы, которые должны оставаться устойчивыми в таких условиях, нужно строить иначе.
Теория остаточности (Residuality Theory) дает на это на удивление ясный ответ.
Residuality Theory — междисциплинарный концептуальный подход, применяемый в экономике, теории фирмы и системной инженерии, согласно которому ключевые свойства системы определяются распределением остаточных (residual) прав, рисков и ответственности, возникающих после исполнения формально описанных правил и контрактов; в ИТ это проявляется в том, кто обладает остаточным контролем над архитектурными решениями, изменениями требований, обработкой edge-cases, инцидентами и неопределённостями, не покрытыми спецификациями или SLA, то есть кто принимает финальное решение и несёт последствия, когда регламенты, код и процессы не дают однозначного ответа — что делает residual authority критическим фактором устойчивости, управляемости и эволюции программных систем.
Если вы ещё не сталкивались с теорией остаточности, рекомендую посмотреть этот доклад: https://www.youtube.com/watch?v=_MPUoiG6w_U
Ключевая идея теории остаточности — и почему она так важна для процессов
О’Рейли утверждает: программное обеспечение и организационные структуры выживают только в том случае, если они состоят из отдельных, уст��йчивых Остатков. Остаток — это то, что остаётся от системы после воздействия стресса. А стресс не является опцией — он гарантирован.
Регулирование меняется, рыночные условия сдвигаются, системы выходят из строя, команды ротируются, появляются новые зависимости.
Чтобы системы выживали в такой среде, им нужны
небольшие, четко определенные единицы,
минимальная связанность,
и способность трансформироваться в новые Остатки
Большие сквозные BPMN‑диаграммы — полная противоположность этому.
Почему кросс-доменные BPMN‑процессы терпят неудачу
Типичные проблемы больших моделей процессов в BPMN можно объяснить через механизмы теории остаточности:
1. Гиперлиминальная связность между доменами
О’Рейли описывает особенно опасную форму связности между компонентами системы — гиперлиминальную связность. Опасность такой зависимости в том, что поначалу она полностью невидима. Команды часто даже не замечают, что разные части их системы скрыто связаны между собой. Только когда на систему воздействует стрессор (внешнее событие или изменение, создающее давление на систему) — например, неожиданный всплеск нагрузки, сбой системы или изменение регулирования, — эти скрытые связи внезапно становятся видимыми и болезненно очевидными.
Именно это и может происходить в монолитном сквозном E2E‑процессе:
Изменение в обработке платежей внезапно приводит к изменениям в заказе.
Изменения в доставке затрагивают процесс оформления заказа.
Одна ошибка влияет на весь процесс целиком.
Все взаимосвязано — но негативные эффекты такой связности проявляются только тогда, когда что‑то идет не так.
2. Почему большее количество узлов (N) и большее количество связей (K) делает систему нестабильной
Чтобы понять, почему большие кросс‑доменные процессы так быстро ломаются под стрессом, стоит кратко заглянуть в суть теории остаточности.
Частично она опирается на исследования Кауфмана, который показал: в сетевых системах сама структура определяет, останется ли система стабильной или перейдет в хаос.
Кауфман обнаружил:
Чем больше элементов (N) в системе,
и чем плотнее эти элементы связаны между собой (K), …тем сильнее система сама себя ограничивает. Она теряет способность свободно переходить в различные устойчивые состояния («аттракторы»).
Ровно такое поведение мы наблюдаем в больших сквозных BPMN‑процессах.
Поскольку такой процесс:
увеличивает N → каждая активность, каждый шлюз, каждое событие — это элемент системы;
резко увеличивает K → все больше элементов связаны друг с другом, домены чаще взаимодействуют и тесно сцепляются.
В итоге получается модель процесса, которая, с точки зрения теории остаточности, структурно не способна формировать устойчивые Остатки.
Это приводит к:
хрупким потокам работ,
неожиданным побочным эффектам,
сложности любых изменений,
и огромным проблемам под нагрузкой.
Слишком много узлов + слишком много связей = процесс, который ломается даже при небольших изменениях.
3. Команды должны синхронизировать изменения — это антипаттерн
Когда несколько доменов сходятся в одной большой BPMN-модели, возникает организационная структура, которая крайне проблематична как с точки зрения теории остаточности, так и с позиции Team Topologies.
Почему? Потому что каждое изменение — сколь угодно малое — внезапно требует синхронизации между командами:
Домен Платежей хочет ввести новое правило → Домен Заказов должен проверить, подходит ли еще диаграмма.
Домен Доставки меняет логику эскалации → Служба обслуживания клиентов должна затронуть свою часть.
Шлюз изменяется → три команды вынуждены координироваться.
Процесс превращается в общий узкий участок. Команды теряют автономию, поток и скорость. При этом возникает классическая проблема владения:
Кто владеет центральным сквозным процессом?
Кто может принимать решения?
Поскольку все находится в единой модели, каждое изменение требует координации между командами.
О’Рейли описывает именно такую структуру как Остаток, порожденный старым централистским мышлением, — и она стоит на пути современных организаций.
4. Данные процесса приобретают кросс-доменную связанность
В большой кросс-доменной BPMN-модели процесса возникают не только логические зависимости между задачами — появляются также скрытые зависимости данных, которые команды едва могут осознать.
То, что на диаграмме выглядит как безобидный поток данных, на деле приводит к глубоким структурным связываниям:
Одна команда записывает данные в процесс, которые ожидает другая команда.
Домены вынуждены согласовывать, кто может изменять или читать какие данные.
Валидации и маппинги из одного домена внезапно становятся частью другого домена.
Проблема в том: эти связывания не видны, пока всё работает гладко. Они проявляются только при воздействии стрессора.
Согласно теории остаточности:
больше зависимостей данных между доменами → выше K
больше полей данных → выше N
При росте N и K количество устойчивых состояний-аттракторов в системе уменьшается. Система способна формировать меньше устойчивых Остатков. Итог? Зависимости данных создают системную хрупкость.
5. Тестирование становится неуправляемым
При росте N и K в процессе может пойти не так гораздо больше вещей. Результат: количество возможных тестовых состояний взрывается.
Тесты становятся все длиннее.
Регрессионные тесты — непредсказуемыми.
Тестовые данные — сложными.
Баги возникают несмотря на высокий охват тестами.
Баги трудно воспроизвести.
Система со слишком большим количеством возможных Остатков больше не может быть осмысленно протестирована.
6. Когнитивная нагрузка растет, процесс адаптации удлиняется
О’Рейли описывает, как люди по‑настоящему понимают домены: не через документы, модели или описания, а через повторный, конкретный опыт взаимодействия с рабочими процессами, решениями и вариациями в домене.
Вы постигаете процесс, переживая его напрямую снова и снова — подобно тому, как не изучаете район по карте, а через многочисленные прогулки по нему.
Большая кросс-доменная модель процесса действует ровно наоборот:
Она заставляет все домены уместиться в единой картинке, которая показывает больше сложности, чем человек способен обработать.
Она создает иллюзию понимания («я вижу все») без настоящего понимания, потому что
слишком много деталей видно одновременно,
слишком много правил переплетаются,
слишком много исключений в одной картинке,
домены смешиваются.
Как мы можем решить эти проблемы?
Описанные проблемы — не единичные случаи, а системные последствия архитектуры, которая не поспевает за современными требованиями. Хорошая новость: есть понятный выход из этой ловушки.
Решение заключается в изменении самой структуры — таким образом, чтобы она была устойчивой с самого основания. Теория остаточности показывает центральные принципы, с помощью которых мы можем строить архитектуры процессов, остающиеся стабильными при стрессе.
1. Разрезаем процессы по границам доменов
Теория остаточности — это не теория модульности: она объясняет, как системы остаются стабильными под стрессом.
А стабильность возникает по естественным разломам системы: доменам.
Домены — устойчивые единицы, потому что они:
имеют свои собственные правила,
владеют своими данными,
несут свою ответственность,
и формируют свои собственные Остатки.
Например, платежи не имеют отношения к доставке. Так зачем связывать внутренности доменов в одном большом процессе?
Когда каждый домен имеет свою BPMN-модель, возникает четкий архитектурный аттрактор: устойчивое состояние, которое поглощает стресс локально, а не распределяет его по всей системе.
Кросс-доменная модель, напротив, размывает эти границы, увеличивает связность и препятствует формированию устойчивых Остатков — именно те ошибки, которых стремится избежать теория остаточности.
Короче: разрезание процессов по границам доменов — это не просто хорошее моделирование, а центральный механизм, чтобы процессные ландшафты действительно оставались стабильными под реальным стрессом.
2. Дополнительная модульность внутри домена
Процесс, разделенный между доменами, имеет четкие внешние границы — но внутри домена часто все еще возникает сложная логика, которая ломается под стрессом, если моделируется как единый большой рабочий процесс.
Поэтому теория остаточности требует, чтобы даже внутри домена возникали структуры, способные формировать малые, устойчивые Остатки. Именно здесь помогают Call Activities:
Они разбивают сложный рабочий процесс на малые, независимые строительные блоки процессов, каждый со своей чёткой задачей.
Каждый строительный блок формирует свой Остаток: управляемый, тестируемый, независимо изменяемый.
Изменения в одном блоке не затрагивают остальной процесс — стресс остается локальным.
Количество элементов (N) и связей (K) внутри домена значительно уменьшается.
Это создаёт больше устойчивых аттракторов, то есть поведенческих паттернов, которые сохраняются под стрессом.
Короче: Call Activities не просто делают домены структурно меньше, а устойчивее. Они обеспечивают, чтобы домены были не только разделены друг от друга, но и внутренне надежны.
3. Общение между доменами только через интерфейсы, никаких BPMN-монолитов
Когда процессы разрезаются по границам доменов, общение между ними тоже должно быть строго регламентировано.
Именно здесь многие организации совершают критическую ошибку: пытаются оркестрировать взаимодействие доменов в одной большой центральной BPMN-модели — паттерн, крайне рискованный как с точки зрения теории остаточности, так и современной организационной архитектуры.
Правило вместо этого: домены общаются не через общие модели процессов, а через чистые, минимальные интерфейсы.
К ним относятся:
События (например, PaymentCompleted, ShipmentCreated)
API с четко определенными входами/выходами
простые триггеры, запускающие процессы домена без раскрытия его внутренней структуры
Такой способ общения имеет ключевое преимущество: одному домену не нужно знать, как устроен другой внутри или как выглядят его Остатки.
Почему этот подход устойчивее согласно теории остаточности
Меньше гиперлиминальной связности → стресс остается локальным, а не глобальным.
N и K резко сокращаются → больше устойчивых аттракторов, никаких огромных хрупких структур.
Остатки становятся малыми, поддерживаемыми и комбинируемыми → система выживает при неизвестных стрессорах.
Команды имеют владение → структуры команд соответствуют техническим моделям.
Изменения не вызывают каскадов → нет эффекта домино через центральные монолиты процессов.
Вывод: Теория остаточности ясно показывает, почему кросс-доменные процессы опасны
Большие модели процессов BPMN — это Остатки из эпохи, когда централизация, контроль и полное картирование процессов казались необходимыми.
Сегодня они создают:
Гиперлиминальную связность
Высокие значения N-K
Хрупкость под стрессом
Неясные ответственности
Сложное тестирование
Теория остаточности показывает лучший путь: разделяйте процессы по естественным границам доменов и моделируйте внутри каждого домена устойчивыми Остатками. Это создает архитектуры процессов, которые действительно справляются с будущим.
Что дальше?
Если вы хотите глубже погрузиться в принципы устойчивых IT-архитектур, рекомендую книгу Барри О’Рейли «Residues: Time, Change, and Uncertainty in Software Architecture». Она дает четкую теоретическую основу для понимания, почему многие кажущиеся правильными архитектуры терпят неудачу — и как строить системы, которые действительно долговечны.
BPM Developers — про бизнес-процессы: новости, гайды, полезная информация и юмор.
