Это в вашем представление "обычно" :) В моем - нет :)

это был типичный вопрос нормального аналитика

Я бы сказал даже - первый возникающий вопрос )

🤝

А твоя модель - она откуда и где используется и как описана?

Из разных источников. Я долго изучал и периодически новое читаю. Можешь начать со статьи Максима Смирнова, правда я ее фиг найду. Она как-то сложно ищется.
И из опыта своего и коллег.
Но в целом разделение между enterprise/solution/software у каждого своего. Единого мнения тут нет, и споры в этом же чате регулярно тут велись сотнями сообщений.

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

Хорошее определение.

коммуникации я бы отдал PO и аналитику, в идеальном мире

Аналитик (в смысле постановщика задачи) в свою очередь отвечает за корректность интерпретации потребностей заинтересованных сторон.

Если мы переходим на уровень solution (и выше, наверное), то тут без коммуникаций никуда.

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

Да, да, это очередной вопрос о курице и яйце. Что первично, ограничения структуры команды, или структура продукта. Рекомендую кстати вот статью:
https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6470589

Она про отношение между постановкой задачи и возможным вариантом решения, если обощать.

Поэтому по моему мнению сейчас solution - это про технико-экономические характеристики, плюс социалку вокруг них. В том числе - культуру разработки.

просто интересно, многие архитекторы согласились бы, если сейчас навесили "обеспечение коммуникаций ЗЛ".
по моему опыту обычно Арх (бородат, волосат и) не сильно комуницируемый

Ну как бы можно гвозди и кирпичами забивать. Но в современном мире нормальные люди используют пневмопистолеты например.

Software - возможно. Хотя не понятно, как он до команды и рп доносит свои решения.
Solution - уже нет. Без коммуникаций никуда

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

Я повторюсь, моё мнение - это что solution раскрывается как техническое решение включая экономическую обоснованность его применения. Доносить про экономику придётся до пиджаков. А если архитектор этого не умеет - значит он некомппетентен.

это безусловно

Я больше ориентируюсь на следующие источники:
- ISO/IEC/IEEE-12207
- ISO/IEC/IEEE-29148
- "Systems engineering handbook. A guide for System Life Cycle Processes and activities." by INCOSE
- SEBOK
- BABOK
, при определении роли аналитиков (бизнес и системных) в процессе жизненного цикла разработки ПО. Где-то эту тему уже обсуждали, и @WatchTh15 хорошо ответил тогда. Я помню, он тогда еще привел в пример "INCOSE Guide for Writing Requirements" by INCOSE - весьма интересный и ценный источник.