AfRel/doc/intro.md

AfRel -- введение

AfRel -- архитектурная методика на основе ресурсных ограничений.

Введение в AfRel (Architecture Framework with Resource Limitations)

Проблема

Существующие подходы к управлению архитектурой (Enterprise Architecture, TOGAF, ArchiMate, UML, SysML) часто страдают от разрыва между «бумажной» архитектурой и материальной реальностью разработки, эксплуатации и бизнеса.

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

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

Базовый императив

AfRel исходит из того, что любая система (бизнес, IT-сервис, код, команда) существует в условиях ограниченных ресурсов (время, деньги, люди, вычислительные мощности, энергия) и стремится реализовать базовый императив выживай.

В переводе на язык архитектуры это означает:

Каждое архитектурное решение должно быть обосновано тем, как оно повышает шансы
системы сохранить своё существование или развиваться в данных условиях.

Если решение или задача не могут быть обоснованы в терминах выживания — они считаются паразитическими (эксплуататорскими, потребительскими) и подлежат исключению или пересмотру.

Основные принципы AfRel

• Материальность — все артефакты (цели, требования, задачи, проверки) имеют измеримые атрибуты по трём осям: количество (X), качество (Y), деньги/ресурсы (Z).
• Трассируемость — каждый артефакт имеет явную ссылку на родительский артефакт (от бизнес-цели до проверки инфраструктуры).
• Неизменность имени — артефакты не переименовываются; при изменении создаётся новый артефакт, старый объявляется устаревшим (deprecated).
• Четырёхчастная структура — на каждом уровне (бизнес, архитектура, софт, инфра) артефакты делятся на:
  • targ (цель, императив)
  • req (требование, условие)
  • task (задача, действие)
  • check (проверка верификации)
• Версионирование — сквозное, четырёхуровневое (x.y.z.b = бизнес.архитектура.софт.инфра), хранится в системе контроля версий (Git) в виде тегов, привязанных к артефактам.
• Автоматизируемая проверка — каждая check должна иметь измеримый критерий и, по возможности, автоматический способ верификации (CI, нагрузочные тесты, финансовая модель).

Основные понятия

Понятие	Описание
Куб выживания	Пространство с осями X (количество), Y (качество), Z (деньги/ресурсы). Любое состояние системы — точка в кубе, любая цель — вектор (траектория) движения.
Артефакт	Поименованный объект в репозитории, содержащий targ , req , task или check и обязательные поля X, Y, Z.
Уровень артефакта	b (business), a (architecture), s (software), i (infrastructure).
Часть артефакта	targ , req , task , check .
Иерархия имён	Строится добавлением цифр без разделителей (например, 1b-targ → 1a1-req → 1a1s1-task ).
Репозиторий бизнес-процесса	Хранит артефакты уровня b и a .
Репозиторий софта/инфры	Хранит код, тесты, скрипты, но версии синхронизируются с бизнес-тегами.

Краткий обзор практик

• Формулировка цели — в терминах X, Y, Z с квадрантом куба выживания (расширение/сжатие, повышение/снижение качества, отток/приток ресурсов).
• Контрольный вопрос — «Как эта цель повышает выживание?» (ответ в котором нет измеримых параметров, времени и денег -- цель не принимается).
• Разложение требований — цель (b-targ) → архитектурные требования (a-req) → задачи (a-task, s-task, i-task) → проверки (a-check, ...).
• Планирование — дорожная карта, где бизнес-задачи (b-task) сопровождаются метками архитектурных задач (a-task) и контрольными точками.
• Автоматическая проверка — CI проверяет наличие обязательных полей, трассировку, неизменность имён, связь тегов с артефактами.

Место AfRel среди других фреймворков

AfRel не заменяет TOGAF, ArchiMate, UML, SysML — он дополняет их, вводя дисциплину материальности и проверки. Вы можете использовать любые нотации для моделирования, но AfRel требует, чтобы каждый элемент модели был привязан к артефакту req , task или check с измеряемыми X, Y, Z.

Таким образом, AfRel — это методология поверх методологий или парадигма управления архитектурой, основанная на ресурсных ограничениях.

Дальнейшие шаги

В последующих разделах документа будут детально описаны:

• Структура артефактов (YAML-схема)
• Кубы выживания и траектории
• Дорожная карта (графическая нотация)
• Версионирование и связи с Git
• Шаблоны чек-листов
• Примеры (правильные и антипаттерны)
• Рекомендации по внедрению