Когда‑то, много лет тому назад, когда я начинал перепрофилироваться с разработчика программного обеспечения на системного и бизнес аналитика, я открыл для себя нотацию описания бизнес процессов BPMN, в частности вторую версию. И настолько хорошо она мне «зашла», что в скором времени, вместо конспектирования интервьюируемого текстом, к концу встречи я набрасывал готовую схему процессов, что помогало сократить время на дополнительные энергозатраты и коммуникации — когда по результатам встречи требуется проанализировать законспектированное, перевести в схематичный вид, провести дополнительную встречу по согласованию нарисованной схемы на предмет всё ли корректно отрисовано, дополнительные корректировки, если что‑то было понято не так...

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

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

В отличии от C4 или Archimate, схемы отражают динамику, а не статику, и при этом позволяют держать масштабный обзор общей картины в рамках решаемой задачи. Они хорошо себя зарекомендовали для решения сложных кроссфункциональных бизнес‑задач, где для достижения бизнес результата требуется доработка в нескольких информационных системах\сервисах с привлечением разных команд разработки, позволяя держать всех участников в едином контексте.

Основная цель использования данной нотации — сокращение энергозатрат и коммуникаций за счёт создания артефактов, которые могут быть прочитаны и понятны без моего участия. Для этого используется максимально простая легенда, чтобы читателю схемы(бизнес пользователю, аналитику, разработчику, тестировщику, специалисту поддержки) не требовалось владеть дополнительными знаниями об элементах нотации, чтобы понять не только контекст, но и динамику приземлённую на конкретный бизнес‑процесс/ решаемую бизнес задачу/проблему.

Ниже легенда по основным элементам, используемым при подготовке схем. По факту 95% компоненты унаследованы из нотации BPMN и поделены на следующие типы:

• Слой информационных систем и сервисов;

• Блоки функциональных требований;

• Тригерные события инициирующие старт процесса;

• Точки интеграции;

• События завершения процесса;

• Инфопотоки;

• Шлюзы;

• Данные.

Слой информационных систем и сервисов

Включает в себя три основных типа систем:

1. Существующие информационные системы\сервисы;

2. Новые информационные системы\сервисы;

3. Технические\интеграционные сервисы.

Блоки функциональных требований

Включает в себя три основных типа блоков:

1. Существующие функциональные блоки;

2. Новые функциональные блоки, либо функциональные блоки требующие доработки в рамках решаемой задачи;

3. Блоки открытых вопросов, по которым следует проработать бизнес требования.

Триггерные события инициирующие старт процесса

Включают в себя три основных типа:

1. Триггерное событие типа «сообщение», инициирующее старт процесса — применимо, когда в качестве начала процесса требуется отразить получение информации пользователем системы\системой.

2. Триггерное событие типа «таймер», инициирующее старт процесса — понимаем, что процесс запускается с какой‑то регулярностью.

3. Любое другое триггерное событие, инициирующее старт процесса.

Точки интеграции

Точки интеграции могут отражать:

• Названия эндпоинтов\методов API при синхронной интеграции;

• Названия топиков Кафка при ассинхронной интеграции;

• Не иметь названий, отражать лишь их наличие.

События завершения процесса

Завершение процесса делится на два типа:

• Завершение процесса с типом «Сообщение» — когда процесс завершается отправкой сообщения;

• Любое другое завершение процесса.

Инфопотоки

Инфопотоки деляться на три типа:

1. Существующие инфопотоки, соответствующие целевой архитектуре;

2. Инфопоток не соответствующий целевой архитектуре — для отражения выявленных проблемных, построенных с архитектурным нарушением, временно‑допустимых информационных потоков.

3. Новые инфопотоки — создаваемые в рамках решения задачи.

Шлюзы

Два основных шлюза для развлетвления либо соединения потоков на базе логического «и» и «или» соответственно.

Данные

Данные разделены на два основных типа:

1. Данные в мастер системе;

2. Данные в системе потребителе данных.

Ниже можно ознакомиться с примером архитектурной схемы интеграции с условным маркетплейсом «A» минимально жизнеспособный продукт по модели FBS, где согласно условной бизнес модели управление каталогом ведётся в системе класса PIM, управление ценообразованием в Системе ценообразования, обработка заказов в системе обработки заказов OMS.

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