* * *
Итоги сегодняшних прений:
1. Идею Диеца о том, что архитектура относится к типам систем, а дизайн к самим системам временно откладываем в сторону. Считаем, что архитектурный дизайн имеет слово "архитектура" для двух надобностей, куда не входит отделение собственно архитектуры от дизайна:
а) перенос принятия крутых решений поближе к началу жизненного цикла. При этом совершенно неважно, это архитектурные или уже дизайн-решения.
б) separation of concerns, разведение интересов -- весь концептуальный фреймворк со стейкхолдерами, их интересами, вью, вьюпойнтами и моделями. Опять же, в таком стиле можно представлять и дизайн-решения, а не только решения архитектурные.
В связи с этим лучше бы говорить "архитектурный дизайн", а не "архитектура" и "дизайн" (следуя в этом ISO 15288). А если речь идет не о продукте а о процессе, то "процесс архитектурного дизайна".
Ну, а в случае предприятия -- Enterprise Architecture доходит до конкретных проектных рекомендаций, просто инструментарий еще не так развит, чтобы из высокоуровневых описаний сразу получались рабочие инструкции (желательно скомпилированные прямо в головы работников) и приложения (желательно скомпилированные прямо для используемых компьютерных платформ). Так что это Enterprise Architectural Design -- набор функциональных требований и соответствующих им конструктивных решений заведения.
2. Концептуальный фреймворк (пункт 5 ISO 42010) описания архитектурного дизайна не покрывает случая с "типовой системой", или "продуктной линией". Его нужно для этого дополнять. И тут можно опять вспомнить Диеца с его пониманием архитектуры, как раз относящимся к "типовой системе". Тут все, что относится к типовой системе -- архитектура, а что относится к конкретной системе -- дизайн. Или же это просто "слои" архитектурного дизайна, для каждого из слоев указывается класс систем в итоге уточняемый до дизайна одной конкретной системы. Пока считаем, что есть "слои" (что сводится к model-driven engineering).
3. Архитектурный дизайн -- это общая концептуальная модель системы, выраженная в (агрегированных во вью) символьных моделях. Общность вроде как обеспечивают правила согласования вьюпойнтов, но непонятно, можно ли считать архитектуру интеграции данных из ISO 18876 (а это ISO 15926, Gellish, современные CAD/CAM-системы типа Intergraph SmartPlant Enterprise и т.д.) примером реализационного (даталогического) механизма таких правил. Еще интересно, что такое модель данных+RDL (для ISO 15926) или Gellish Smart Dictionary/Taxonomy, или SPF Schema при таком подходе: куда ее включать -- во вьюпойнты (например, во вьюпойнт, имеющий дело с интересами архитектора, относящимися к интеграции моделей архитектурного дизайна) или отдельным элементом описания архитектурного дизайна, непомянутым в концептуальном фреймворке пункта 5 ISO 15926, или считать, что это все реализационные средства -- но как быть тогда с идеей Gellish и SPF Schema, в которых такие модели, как PBS и WBS плавно вырастают из predefined словарей?
Итого: все еще довольно мутно, но понятно, куда плыть.