Напоминаю: на данном этапе я - заказчик, и могу городить любую херню, которую в принципе хочу. На проекте у нас есть аналитик — Роман Данилов. Поэтому этот пост — альтернатива сбора требований. Ну а потом уже придёт Роман и расскажет нам, какие тут требования какие если опять не перепутает, а какие вообще не требования. Разложит это красиво по полочкам и расскажет, что делать разработчику. Ну или не придёт.

Вполне очевидно: ЕАР должен иметь два основных «хребта» связи информации: с метаданными и с бизнес-процессами.

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

Что касается бизнес-процессов. Нормально описать подобную взаимосвязь исключительно вертикально - просто не возможно, необходимо определить «слоистость».

Основной родительский слой обеспечивает связность всех остальных и использует описание цепочкой
Бизнес-роль ➡️ выполняет➡️ Бизнес-процесс➡️ поддерживается ➡️ IT-сервисом ➡️ реализуется➡️ Узлом инфраструктуры.

Слой бизнес-процесса должен поддерживать иерархическую декомпозицию Процесс➡️Подпроцесс➡️Шаг

Слой решения описывается моделью C4 Context➡️Container➡️Component➡️Code.
Уровень Context в этой модели совпадает с IT-сервис в родительском слое, и по сути, расширяет Узел архитектуры до конкретного решения.

Почему именно так? Ну это упрощенный набор базовых подходов - ArchiMate, BPMN и С4 - де-факто являющимися стандартами в IT-индустрии. Они чётко структурированы, позволяют легко проводить масштабирование и использовать навигацию zoom-in/zoom-out. Ну и обеспечивают должное понимание на необходимых уровнях заинтересованности и для бизнеса, и для ИТ.

Логичным итогом подхода должна стать визуализация в виде модели графов связей и влияний.

Теперь немного о наполнении сущностей. Понятно, что каждая сущность должна иметь связи, определеяющие её горизонтальное и вертикальное положение - этот момент я в дальнейшем упущу. Как и то, что каждая сущность должна иметь индентификатор, подчиняющийся определенным правилами, и название, понятное и бизнесу, и IT. Еще пожалуй статусную модель.

Бизнес-роль BR-
▪️Описание выполняемых функций
▪️Положение в структуре компании
▪️Текущий исполнитель

Бизнес-процесс BP-
▪️Степень критичности Насколько процесс важен для компании. Достаточно относительной степени сравнения (обычный, важный, очень важный), но необходима опциональная возможность добавить SLA/RTO/RPO
▪️Триггеры События, запускающие процесс
▪️Описание входов/выходов процесса

Элемент архитектуры ARC-
▪️Tech owner Кто отвечает за разработку и поддержку.
▪️Точки интеграции Предоставляемые и получаемые.
▪️Этап жизненного цикла

Задача TASK-
▪️Приоритет
▪️Тип Новый функционал, техдолг, интеграция, аналитика.
▪️Контекст

Решение ADR-
▪️Процесс принятия решения Рассмотренные варианты, обоснование выбора, ответственный за принятие решений, дата принятия решения, автор/исполнитель принятого решения
▪️Известные последствия Техдолг, безопасность, производительность, нетипичная работа с данными
▪️Связь с замещающим решением

Точки интеграции INT-
▪️Компоненты
▪️Направленность
▪️Протокол/механизм
▪️Формат данных
▪️Ответственная команда
▪️Описание спусковых механизмов
▪️Описание контракта

Пожалуй, по основным требованиям всё. Есть еще дополнительные. Их я включу в следующий пост (тут уже места нет)

Утверждён график выхода ближайших серий
10.04 - ЕАР. Концепция. Часть III. Точки роста и риски.

#МедведьДелаетЕАР