Ограничения архитектуры Architecture Constraints · UAF
Простыми словами
Ячейка Управление архитектурой × Ограничения держит допущения и ограничения САМОГО описания архитектуры: на чём построена работа, где проходят её границы, какие правила и руководящие указания над ней действуют. Это не ограничения предприятия — их место в стратегической строке, где меры ограничивают способности, и не сервисные политики. Элемент вида ровно один: описание архитектуры (ArchitecturalDescription) со свойством assumptionAndConstraint, то есть содержимое ячейки — текст, привязанный к описанию, а не схема. Формы соответствующие: диаграмма пакетов SysML или таблица. Читателю ячейка нужна, чтобы понимать, чему в модели верить: неназванное допущение — самый частый источник неверных выводов из чужой архитектуры.
Примеры
Определение всей строки прямое: «Provide information pertinent to the entire architecture. Present supporting information rather than architectural models.» Поэтому и ограничения здесь — сопроводительный текст, а не конструкция.
UAF DMM 1.3, разд. 8.1.1 — Definition строки Architecture Management
Определение вида называет пять вещей: «depicts and analyzes assumptions, constraints, rules, policy and guidance that are applicable to aspects of the architecture.» Обратите внимание на конец фразы: ограничения относятся к аспектам архитектуры, то есть к столбцам сетки, а не к предприятию.
UAF DMM 1.3, разд. 8.1.1 — Definition вида Architecture Constraints
Четыре ячейки этой строки — ограничения, метод разработки, статус и дорожная карта — имеют один и тот же единственный элемент, ArchitecturalDescription. Различаются они тем, какое его свойство выведено на схему: здесь допущение и ограничение, там методология, статус, версия.
UAF DMM 1.3, разд. 8.1.1 — перечни Elements под рис. 8-8, 8-4, 8-5 и 8-9
Определение из первоисточника
дословная выпискаdepicts and analyzes assumptions, constraints, rules, policy and guidance that are applicable to aspects of the architecture.
Отображает и анализирует допущения, ограничения, правила, политику и руководящие указания, применимые к аспектам архитектуры.
Как этим пользуются
Описание представления в источнике: для кого оно нужно, что описывает и в каком виде.
- Кому нужно
- Корпоративные архитекторы
- лица, желающие понять ограничения архитектуры
- технические руководители
- Что закрывает
предпосылки и ограничения архитектуры.
- Из чего состоит
- В каком виде рисуют
- Диаграмма пакетов SysML, табличный формат
То же в оригинале
- Кому нужно
- Enterprise Architects
- people who want to understand the architecture constraints
- Technical Managers
- Что закрывает
architecture assumptions and constraints.
- Из чего состоит
- ArchitecturalDescription
- В каком виде рисуют
- SysML Package Diagram, tabular format
Основные параметры
Атрибуты этой сущности по справочнику источника.
- Stakeholders: Enterprise Architects, people who want to understand the architecture constraints, Technical Managers.
- Concerns: architecture assumptions and constraints.
- Recommended Implementation: SysML Package Diagram, tabular format.
В других подходах
Сопоставления одного понятия в разных подходах.
Аспект сетки: ограничения.
Семантические различия Не путать со строкой «Constraint» (единственное число) — там сущность метамодели, здесь столбец сетки.
Корпоративные архитектуры
- UAFArchitecture Constraints
- UAFStrategic Constraints
- UAFOperational Constraints
- UAFServices Constraints
- UAFPersonnel Constraints: Competence
- UAFPersonnel Constraints: Drivers
- UAFPersonnel Constraints: Performance
- UAFResources Constraints
- UAFSecurity Constraints
- NAFC8 - Planning Constraints
- NAFS8 - Service Constraints
- NAFL8 - Logical Constraints
- NAFP8 - Resource Constraints
- NAFA8 - Architecture Standards
Связанные понятия
Опишите архитектуру своей компании в Storm
Реестр процессов, архитектурное рабочее пространство, связи между системами и процессами — те самые артефакты, только про вашу организацию.
Это же в StormРазработка ТЗРегламенты и политикиРеестр процессов