Недавно написал такой текст
——-
Основная задача роли "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

Для меня БД, приложения, технологии относятся к технической части, дели их на домены или не дели

Я все, слишком много новых понятий, они начинают размножаться. Чтобы объяснить АО ввели ещё дюжину непонятностей

Подсказка, объяснять надо через понятно сти а не плодить непонятности

" The architecture owner is the person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design."

Солюшен с яйцами, короче )

Солюшен с яйцами, короче )

Я вот не понимаю в чём отличие от архитектора.

В том, какой мотив и какая рамка удержания целостности.

Или ты снаружи продукта, и консультируешь
Или ты внутри продуктов, и живёшь в продуктовом подходе
Или ты передаёшь Архитектуру как роль команде, и помогаешь в сложные минуты

Кто помогает продукту понять, что изменится, если они перепишут часть приложения X и не будут делать US Y и не будут переходить на асинхронную очередь Z?

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

У нас роль архитектора у нас, разработка в подрядчике. Команда по проекту включает архитектора, аналитика и прочих, но не все постоянно работают вместе. Разработка идёт, в основном, по SCRUM. Аналитики и архитекторы могут привлекаться по необходимости. Владельцы продуктов занимаются развитием продукта параллельно.