Архитектура чего? Инфраструктура - совокупность физических объектов. Архитектура - концептуальная структура, принципиальная организация, т.е. абстракция, модель.

Архитектура - всегда какой-то системы.

Инфраструктура - всегда ДЛЯ каких-то систем.

Архитектура - концепт системы (грубо). Отношение репрезентации. Системы ПОСТРОЕНЫ НА инфраструктуре. Отношение использования.

Мне помнится интересное определение от препода - архитектура всегда решает какую-либо проблему, а инфраструктура - это то что у нас есть (она ничего не решает). Само собой в рамках систем.

Схожесть слов - случайна :)

""Дорожная инфраструктура", и мы мыслим логистику компании" - не надо так писать.
"Мыслим" в этой фразе == "представляем как устроен x", а не "придумываем на основании x".
Используйте слова правильно )

Сорри, тут действительно телеграфным текстом...

А то я прочитал как написано, а не что имелось в виду ))

Хороший кейс для разминки: дать определение понятий "архитектура инфраструктуры" и "инфраструктура архитектуры"

сразу все вопросы снимутся

У архитектуры как таковой инфраструктуры нет, т.к. архитектура - не система в точном смысле :)

А у инфраструктуры (какой-то системы) архитектура вполне может найтись, если эту инфраструктуру саму  рассмотреть как цельную систему. Понятие, естественно, не меняется.

Я бы поспорил насчет большой команды.

Если в классическом понимании, а не как синоним "группы сотрудников" -- то там же требуется высокий cohesion и interdependence, по определению.

Команды не масштабируются, но из них можно строить суперструктуры.

В «классическом» - я с вами соглашусь. Наверное вопрос звучит как «как строить такие суперструктуры» в парадигме end-to-end продуктовых команд и где там может быть саппорт/ответственность за полный жизненный цикл продукта (а не принцип - разработали, выкинули, авось там ктонить разберется).

1. У меня нет готового ответа, к сожалению. Тоже ищу!

2. На команде размером "2 pizza" все работает, и решение тривиально. Отсюда интересное следствие -- вся эта тёплая ламповость немасштабируемых крафтовых продуктов / сервисов.

3. Есть работающий паттерн -- склеить support с клиентским саппортом. Эти всякие customer excellence team, хотя и затаскано.
Плюсы -- support перестаёт быть унылым и безвыходным местом.
Минусы.. как я понимаю, технически продукт (инстанс?) будет деградировать сильно быстрее. Но разделение на слои  (платформа / конфигурация клиента) должно сгладить эффект.

Я, пока что, не видел успешных Agile команд больше 10 человек. Обычно дальше сразу становился вопрос о разделении на 2 маленькие команды с зонами ответственност в компонент/сервис. Обычно выделялся отдельный "условный ПО для компонента" и он уже тащил.  Интересно, если есть примеры как это было реализовано на практике.

Саш, про Agile я не говорил. Посмотри внимательно;)

Прошу прощения) Просто в контексте мелькали термины ПО/СМ, и проассоциировал)

Наблюдаю сейчас за двумя командами, объединенными по LeSS методологии. Осень покажет, насколько успешны будут.
В лесс евангелисты говорят можно до 90 чел отмасштабировать. Посмотрим...