ArchiMetal Case Study, Version 3.1
https://publications.opengroup.org/y195

ну, вся проблема-то, что большинство источников про версию 2.1, а по 3.1 все пока только за деньги (точнее членство в OG).
По первой ссылке тоже не раз выходил из гугла... но и там общая проблема - большинство примеров обезличены и абстрактны.
В целом в сети очень мало описаний с конкретными названиями элементов (а не просто "Application process", "Application component" и т.д.

простой пример вопрос - как на технологической схеме отображать порты ?
мы в итоге пришли к использованию компонента " Path"... но насколько это верно ?

как написал выше - на OG материалы есть... но я не член AG. например... а просто так чтобы самому купить даже - нет возможности. насколько я понял 😞
Возможно что-то не дополнял

Мы порты делаем как специализацию от Technology Interface. А скажем сетевые интерфейсы как специализацию от Path

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

Там не обязательно быть совсем членом, достаточно сдать сертификацию TOGAF

ye? lf? fh[biehtyc jy gjyznyjcnb yt jcj,tyyj lj,fdkztn/// ghb njv? xnj jy b d lheub[ bcnjxybrf[ rjgbgfcnbncz

ну, я зарегился кстати 😊
что-то скачать получилось 😊

» В целом в сети очень мало описаний с конкретными названиями элементов

Может быть, потому, что "концептуально-обозначенный элемент" не равно "этот, конкретный элемент"?

На входе в Archimate сказано:

" 2.14   Model
A collection of concepts in the context of the ArchiMate language structure. For a general definition of model, see the TOGAF framework [4]."

||

Смотрим:
" 3.15 Architecture Model
A representation of a subject of interest.

An architecture model provides a smaller scale, simplified, and/or abstract representation of the subject matter."

Да, Open Group очень не любит рассматривать примеры конкретных существующих в единственном экземпляре объектов (инстансов). Считает, что это уже не архитектура. Архитектура предприятия (да и решений) - архитектура типов объектов, а не инстансов.

"3.52 Modeling
A technique through construction of models which enables a subject to be represented in a form that enables reasoning, insight, and clarity concerning the essence of the subject matter."

Подобные фразы были "просто ни о чём" уже 40 лет назад (первый релиз AutoCAD - 1979 год).

В том числе, поэтому, нужно нам немного напрячься - и отделить "рисование в стиле IT-натурреализма" от проектирования от архитектуры.

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

Но это вопрос холиварный

» без привлечения единичных инстансов могут не читаться в модели.
С этим не спорю - а, наоборот, говорю, что нужно жить в реальности и спускаться к инстансам из моделлера (например, о том, есть ли конкретно ЭТОТ элемент в инфраструктуре, или это "мечта архитектора")

Я тут к тому, что это принципиально три разные деятельности.
Рынок проектирования сейчас доступен из реальностей продуктовой разработки.

По понятным причинам, ищут  не "проектировщика цифрового продукта" (реальная, казалось бы, потребность), а  "солюшен архитектора".
И ничего, что оба слова мимо реальной потребности и деятельности.

Коллеги, хочется задать вопрос, на который я каждый раз слышу разные ответы, но всё же.
Работая системным аналитиком я уже выполняю частично задачи архитектора, но никак не могу понять, какие фундаментальные отличия существуют между этими работами. Да, нужен более высокий уровень абстракции, да, нужно изучать технологический стек и уметь его внедрять, да, нужно иметь опыт успешных внедрений и использования технологий. Понятно, что архитекторов бывает много, в основном я сейчас вижу Enterprise (занимающиеся бизнесом) и Solution (занимающиеся технологиями). Но на своей работе как системного аналитика мне приходится выбирать технологические решения, разгребать вопросы бизнеса и работать как БА, понимать как масштабируются решения внутри компании и как они будут развиваться в течении нескольких лет, заниматься изменением внутренней структуры (распиливать монолит на микросервисы, создавать API, разбираться с брокерами и т.д.).
И вот кажется, работай так и через 3-5 лет можно думать стать архитектором. Или нет? Или упускается какой-то основной смысл архитектора как профессии, который надо изучить и понять?

Звучит круто для SA. Это где ты так прокачался?