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

Давай скажу конкретнее - обучив команду способам генерации модельных описаний и способам object discovery  - мы передаём команде позицию "таак, а как вот это устроено? И что зааффектит изменение в  ...? Слушай, а можем ли мы ..?".

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

В Digial-мире не хватает простых понятных социологам, психологам, психофизиологам понятий.
Например "многопозиционная интерсубъективность" Альфреда Шюца объясняла бы, что такое "роль в продуктовой команде", а "Общая и театральная психология" Савостьянова помогала бы узнать, что между ролью актёра и ролью в продуктовой команде нет большой разницы.

Но да, в Digital идут же за цифровым бессмертием ...

Это всё у Бёрна есть

У Бёрна железобетонный дискурс, ни вправо и ни влево от него: матрица два на три слишком мала.
Хейзинга с Homo Ludens гибче. Или Бронислав Виногродский с "Искусство игры с миром"

Ну вообще-то НИ, Ни, ну ладно. А классика, конечно, не императив, но все-таки базис

Ого, благодарю. Явный показатель "пора отдыхать".

Есть у кого отклик на этот текст? Или своё понимание роли "владелец продуктовой архитектуры"?

Недавно написал такой текст
——-
Основная задача роли "Architecture owner" - вместе с "работающим продуктом" (Agile manifesto, вторая строка) доставлять решение, которое:
1) синхронизировано с процессами/жизненными циклами (ЖЦ) трёх основных продуктовых доменов (Customer, MVP, EA)
2) обеспечивает согласование между пользователями, командой и EA о возможных вариантах нарушения ЖЦ через модель ограничений
3) создаёт предпосылки к такому изменению ЖЦ в доменах Customer/MVP/EA, которое уменьшает их внутренние долги по отношению друг к другу (cross-debt).

Таким образом, есть четыре основных вектора действия роли "Architecture owner":
 - Работа с командой над пониманием процессов/жизненных циклов пользователей продукта и их ограничений (домен Customer)
 - Работа с командой над пониманием собственных процессов/жизненных циклов и их ограничений (домен MVP)
 - Взаимодействие с ролью "Enterprise Architect" над пониманием EA-процессов/жизненных циклов и их ограничений (домен EA)
 - Работа по уменьшению cross-debt

Как-то оно противоречит принципу, что лучшие архитектурные решения создаются самоорганизующимися командами. Один человек не способен в одиночку эффективно решать задачу развития системы.
Вообще при прочтении agile-манифеста в первую очередь нужно руководствоваться 12 принципами. Ценности Agile определяют, то на основании чего делается выбор при принятии решений.
Понятие ЖЦ домена мне лично непонятно. Что вообще такое ЖЦ в Agile? Это видимо, когда бизнес закрывается. Все остально имеет тот же ЖЦ, что и сам бизнес.

А с чего бы это лучшие арх.решения делаются командами?

Не знаю. Так показали наблюдения. Манифест целиком составлен на основании эмпирически полученных данных. Мои личные наблюдения показывают тоже самое.
Но Вы убрали ключевое слово САМООРГАНИЗОВАННЫМИ

Вы читали второй манифест?
Beyond agile manifesto?
В нем Бэк говорит "ребята, достраиваем ещё этаж, так как agile манифест - это жопокрыл - летать можно, если знаешь заранее вариации падения"

Я один это вижу? The best architectures, requirements, and designs  emerge from self-organizing teams.