Онбоардинг не рассматриваю, это исключительный случай. Его можно и устно провести на основании 3-4 диаграмм (сервисы, компоненты, развертывание).

А зачем разработчику вообще ревью и обратная связь по уже написанному сервису, если это не стадия начала разработки? Он ее запросил сам?

Иногда надо соседнейкэ команде законтрибьютить;
Онбординг новых участников команды;
Инфа для опсов и инфраструктурщиков;
Инфа для безопасников;

В проект, где у вас много сервисов.

Я пока рассматриваю вариант, что архитектор требует чего-то от команды в ситуации, когда с ИБ, инфраструктурой и поддержкой команда уже разобралась без участия архитектора (возможно имея внутреннюю неформализованную документацию)

У разработчиков вообще нет проблем. У них есть IDE и зарплата.

Руководству, заказчику, клиенту.

+

Тогда мы спускаемся к ситуации «делай, я тебе за это деньги плачу». Тогда не надо удивляться, что разработчики будут это делать спустя рукава, так как ни для кого выгоды не видят (кроме архитектора — ему KPI по числу описанных сервисов закрывать). То, что АрхКом умудрился продать заказчику составление этой документации (при 100+ сервисах заказчик туда сам то не полезет) тоже ведь не аргумент о том, что клиенту это надо.

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

Контрибьютить внутрь сервиса? Тут ни один «внешний» дизайн-документ не поможет, тут надо опускаться в детали реализации. Это уже точно не уровень документации для архитектора.

Вот конкретно этот шаблон появился вместе с задачей на Арх Надзор от Председателя совета директоров.

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

Вот вообще не верю.

Это следующий шаг.

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

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

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

Он полезет в список используемых библиотек? Будет разбираться в потоках данных? Нет. Ему нужна какая-то агрегированная статистика и экспертная оценка.

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

)))

Ну вам виднее.

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