|
|
@@ -1,3 +1,80 @@
|
|
|
# AfRel -- введение
|
|
|
|
|
|
-**AfRel** -- архитектурная методика на основе ресурсных ограничений.
|
|
|
+**AfRel** -- архитектурная методика на основе ресурсных ограничений.
|
|
|
+
|
|
|
+## Введение в AfRel (Architecture Framework with Resource Limitations)
|
|
|
+
|
|
|
+## Проблема
|
|
|
+
|
|
|
+Существующие подходы к управлению архитектурой (**Enterprise Architecture**, **TOGAF**, **ArchiMate**, **UML**, **SysML**) часто страдают от разрыва между «бумажной» архитектурой и материальной реальностью разработки, эксплуатации и бизнеса.
|
|
|
+
|
|
|
+* Требования теряются в переходах между уровнями.
|
|
|
+* Архитектурные решения принимаются без проверяемой связи с бизнес-целями.
|
|
|
+* Деньги, время и усилия тратятся на «паразитические» задачи — те, которые не повышают способность системы выживать в меняющейся среде.
|
|
|
+* Документация версионируется вручную, трассировка исчезает, ответственность размывается.
|
|
|
+
|
|
|
+**AfRel** предлагает материалистический способ организации архитектурной деятельности, основанный на жёсткой, но прагматичной системе артефактов, версий и проверок.
|
|
|
+
|
|
|
+## Базовый императив
|
|
|
+
|
|
|
+**AfRel** исходит из того, что любая система (бизнес, IT-сервис, код, команда) существует в условиях ограниченных ресурсов (время, деньги, люди, вычислительные мощности, энергия) и стремится реализовать базовый императив *выживай*.
|
|
|
+
|
|
|
+В переводе на язык архитектуры это означает:
|
|
|
+
|
|
|
+```text
|
|
|
+Каждое архитектурное решение должно быть обосновано тем, как оно повышает шансы
|
|
|
+системы сохранить своё существование или развиваться в данных условиях.
|
|
|
+```
|
|
|
+
|
|
|
+Если решение или задача не могут быть обоснованы в терминах выживания — они считаются паразитическими (эксплуататорскими, потребительскими) и подлежат исключению или пересмотру.
|
|
|
+
|
|
|
+## Основные принципы 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
|
|
|
+* Шаблоны чек-листов
|
|
|
+* Примеры (правильные и антипаттерны)
|
|
|
+* Рекомендации по внедрению
|
SVI