Если не вдаваться в детали, то да. Хотя LeSS это всего лишь один из вариантов. Нюансы, конечно, есть. Но давайте ближе к архитектуре

Ну если ведешь разработку, скажем в армии, то там тоже не забалуешь. Устав есть устав. Но давайте не мешать в одну кучу объективную оценку и особенности корпоративной культуры.

так всё-таки в соседнюю ветку? 😊

Andrei второй кусок почвы под моим вопросом - дискуссия вчера и сегодня МС vs СОА. Как я из нее понял (подчеркну других источников не имел к текущему моменту) возможно ошибочно, что в отличие от парадигмы сервис ориентированной архитектуры качественное отличие микросервисов - это то, что предлагается подход. Т.е. некоторый набор методов и методик мы два дня в споре противоставляем некой/некоторой https://ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%80%D0%B0%D0%B4%D0%B8%D0%B3%D0%BC%D0%B0_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F.  Я не ошибаюсь?

SOA как и MSA - это архитектурные стили. Архитектурный стиль, если кратко, это совокупность принципов и паттернов. SOA - зрелый архитектурный стиль, для которого определены стратегические цели, принципы и паттерны, которые согласованы между собой (Erl, http://soaschool.com

Можно сказать, что архитектурный стиль это архитектурная парадигма

MSA - не зрелый архитектурный стиль

Часто парадигма подменяется конкретной имплементацией. Например, говорят, что SOA - это ESB. Приведу аналогию, вот камасутра - это SOA, а миссионерская поза - ESB

Если уж и обсуждать имплементацию, то нужно это делать в конкретном контексте. Парадигма же, не зависит от контекста

попробуй продолжить аналогию для MSA👍

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

Согласен, я за то, чтобы разделять SOA и MSA. Мне нравится, как сказал Марк Ричардс - SOA и MSA, это Service Based архитектуры, где сервис - основной строительный блок

Приведу ещё одну аналогию, если упаковать все функции программы в один класс, это не сделает программу обьектно ориентированной. Впрочем, уверен, с этим многие не согласятся:)

Тут нужен мозговой штурм:)

боюсь, что это, как раньше говорили: "свальный грех".😂

Очень похоже на то ))

Я думаю, что роль esb в msa выполняет набор соглашений и практик таких как rest, http, mq. То есть в парадигме тупого транспорта esb раскладывается на составляющие и в контекст выбираются необходимые паттерны.

Если я правильно понял вопрос (если не правильно - скорректируйте), то под углом академического стиля и личной практики, то я в жизни сталкивался, что под "архитектор" понимают:
- с позиции терминологии, принятой в большинстве ИТ*:
 - enterprise arch (часто "политик-продавец", бывший топ);
 - solution arch (не менеджер, но иногда с менеджерским прошлым, часто составляет ЖЦ проекта);
 - sw/system (без буквы s в конце) arch (часто совмещает team lead);
= с позиции терминологии, принятой в системной инженерии (с буквой s в конце слова system)
 - systems architect (не менеджер обычно);
 - systems engineer (иногда менеджер; даже если не менеджер, то составляет жизненный цикл системы, а следовательно и очень часто жизненный цикл проекта; NB! ЖЦ системы в моей практике очень близко с архитектурой обеспечивающей системы).

Ответ на вопрос так же может быть связан с понятиями из системной инженерии - там есть четкое ролевое разделение инженерия/управление: инженер делает инженерную работу - говорит как создавать что-то (архитектуру, требования, и др.); управленец обеспечивает деятельность.
Системный инженер понимает какие работы нужно сделать с определением и воплощением системы, а управленец понимает, можно ли вообще эти работы выполнить - есть ли прибыль, есть ли подрядчики; следит за логистикой, оплатой.
Оба имеют огромное влияние на систему - оба могут закрыть проект, оба влияют друг на друга.

P.S. Название пишу по-английски т.к. по-русски все переводится очень по-разному

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

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