Не так давно я писал, что что нотации - это не просто способ рисовать квадратики со стрелочками, а в первую очередь - инструмент структурирования мышления аналитика или архитектора. Сегодня хочу показать это на конкретном примере — нотации EPC (Event-driven Process Chain).

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

При попытке описать автоматизируемый процесс терминах EPC невольно задаёшься вопросами:
- Какие события случаются в процессе или в каких состояниях бывают объекты, задействованные в процессе?
- Какие действия переводят объекты из одного состояния в другое?
- Кто или что выполняет эти действия?
- Какая информация и какие ресурсы нужны для выполнения действий?

Можно провести определенные параллели этой нотации с концепцией Event Storming. Оранжевые стикеры событий и синие стикеры команд в Event Storming — это почти те же события и функции из EPC, только в более неформальном виде. Но есть нюанс, в Event Storming подразумевается, что событие триггерит команду (т.е. событие достаточно для запуска команды), а в EPC связь между событием и функцией означает, что функция может исполняться только после наступления определенного события, т.е. событие/состояние необходимо для функции, но недостаточно. EPC дополнительно уделяет внимание информационным потокам, исполнителям и другим ресурсам, необходимым для работы функций.

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

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

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

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

Не скажу, что я супер строго следовал нотации, когда рисовал эти модели. Как я уже говорил, важна не сама нотация, важна картина мира, которая создается с её помощью, аспекты, которые нотация подсвечивает и делает явными.

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