Главный камень - заствить всех проектировать в инструменте по этим самым единым правилам. Т.к. разные департаменты\отделы\команды\индивиды могут тормозить, поэтому надо чтобы либо все согласились, либо командно-принудительно

Это самая большая проблема - внедрить изменение)) но это же для вас не новость)

Внедрение единой методологии будет тем успешнее, чем больше интересов оно учтёт. Поэтому и вопрос про подводные камни.

Юрий! так что вы нас то мучаете! Идите и опрашивайте ваших стейкхолдеров!

Собирайте требования, создавайте методологию, согласовывайте, пробуйте, меняйте

это проблема временная и решается оршанизационно один раз... хотя и долго...
а вот если вы выбрали неправильную интепретацию стандарта, и потом приходите в тупик, потому что чего-то не учли - вот тогда переделывание всех моделей становится для вас неприятным риском

На самом деле основная цель ArchiMate прослеживается: сделать единую нотацию для автоматизации проектирования в TOGAF.

Потому что без единой нотации это получается кому PBMN, кому UML, кому Data Flow. А тут они вроде взяли кучу практик и замесили их в одну нотацию.

А дальше собственно все всё равно в свои нотации уходят. Т.е. Archimate для HLA, а дальше уже каждое подразделение в своей нотации, а иногда и вовсе в своей системе живёт.

Все верно. Это как кто-то на русском говорит, кто-то на французском; но когда им нужно вместе пообщаться, все говорят на английском.

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

Вот это точно, все зависит от вашего фреймворка или его вариаций. Так же в рамках процесса можно изменять объект, а можно не трогать объект, а изменять его состояние.

Друзья, товарищи, может кто знает подскажите где можно почитать про оси вариативности ?

Интересно про описание архитектуры предприятия псевдокодом

Нагло хвастаюсь тем, что мы делаем с айтишной поддержкой работы Школы: все занятия и семинары у нас как шли, так и идут дистантно, на MS Teams сидит уже полтора десятка человек, и в это воскресенье новая группа "Системный менеджмент и стратегирование" пойдёт уже на MS Teams. Формулирую достоинства и недостаки MS Teams по трём категориям пользователей. Рассказываю о текстовом псевдокоде архитектуры предприятия. Обсуждаю табло поддержки образования в трансдисциплинах и обеспечения/enabling себя (по линии жизни по интересам, зарешайства, адрамонтессори). Онлайн-курс системного мышления проходят более трёхсот человек, а сертификат там получило уже десятеро.

https://ailev.livejournal.com/1510391.html

Так решил для себя:
Система это крупное решение. С их помощью можно быстро очень быстро описать весь ландшафт заказчика. Сами системы могут быть очень об разном. Например, в компании предоставляющих чат на сайте это может быть Система чата (главный продукт), Система CRM, Система бухгалтерского учета, Система контроля учета доступа.

Подсистема - крупные, достаточно независимые блоки системы. Для системы чата это Подсисистема коммуникационной платформы, Подсистема Личный кабинет, Подсистема сбора статистики и онлайн мониторинга. Подсистемы связаны между собой интеграционными блоками.

Компонент - обособленная часть системы. В ТЗ (квазигостовое которое) выгружается компонентная схема и для каждой компоненты прописываются функции. Как это будет реализовано технически на данном этапе непонятно. Для подсистемы коммуникационной платформы это может быть Компонент АРМ Оператора, Компонент коммуникационного ядра, Компонент виджета, Компонент интеграций с другими система. Компоненты плотно связаны между собой и часто без каких-либо интеграций слоев, просто используя предоставляемое API. Компоненты содержат функции, которые также определены в ТЗ.

Модуль - конкретные приложения, их которых состоит компонент. У меня модуль это непосредственно исполняемое приложения. Условно - докер конетейнер (не запущенный, а который можно запустить). Между модулями раскидываются функции компонента так, чтобы каждая функция была реализована в каком-либо модуле. Для Компонента коммуникационной платформы это может быть Модуль истории коммуникации за которым спрятан СУБД и ElasticSearch, Модуль маршуртизации, Модуль надежной доставки.

Уровень общения примерно такой. Большие начальники мыслят системами. Начальники поменьше  - подсистемами. Руководители проектов подсистемами и модулями. Разработчики модулями. По документам - системы и подсистемы это уровень презентаций. Компонентная схема - ТЗ, Модульная схема - проектной решение/ЧТЗ.

Схема проверена на паре заказчиков, воспринимается хорошо. Когда первый раз делал декомпозицию на приложения у меня там были по привычки Сервис доступ к данным, Шлюз интеграции, Сервис расчета - заказчик не понял. Переделал на Модуль доступа к данным, Модуль шлюза интеграции, Модуль расчет - заказчик понял ))

Забыл написать. В реалиях разделение на системы/подсистемы/компоненты может иметь политический и финансовый аспект. Например, разработка какой-то компоненты стоит очень дорого, и поэтому ее гордо называют подсистемой. Или надо по каким-то причинам поместить часть системы в компонент другой системы. И компонент становится модулем.

Продолжаем набирать статистику не очень активно,к последнему результату лично от меня 6 кейсов(возможны пересечения) . Кто не успел пройти опрос, проходите)

Индустрии