Закон Конвея звучит в вольном переводе так: Любая организация, которая проектирует систему (в широком смысле), создаст проект, структура которого будет копией коммуникационной структуры организации.

Фишка его в том, что он действует (привет тем, кто считает иначе), но с точки зрения бизнеса имеет один важный изъян — не защищает от изменений. Люди в компаниях меняются. Организационные структуры меняются. Команды меняются. Но производство не останавливается. Спроектированные в «прошлой жизни» системы становятся дико неудобными в разработке, нестабильными и с кучей накладных расходов — они идут против закона.

Устройство среднего по больнице мира:

1. Под давлением изменений в большинстве случаев большие системы, которые мы делаем — какашка.
2. Люди уходят.
3. Команды меняются, цепляются люди с другой культурой, опытом и подходами.
4. Бизнес-цели и задачи также меняются во времени.
5. И т.д.

Имеет место два серьезных зла — текучка в людях и аджайл головного мозга у лиц, принимающих решения. Первое кмк менее зло.

Компании массово меняются с бешеной скоростью и в произвольных направлениях.

Можно бесконечно спорить на эту тему, но опорный план в виде стратегии у рулей должен быть. В том числе и по причине его отсутствия конторы любят переписывать свой софт раз в пару лет. Новые менеджеры (эффективные по большей части) спать не могут без реформ. В отсутствии стратегии через пару лет в компании люди сменятся, а вместе с ними уйдет первоначальный замысел — т.е. некоторая стратегия, которую коллеги сочинили и следовали ей, пока колбасили продукт. Соответственно, если ее нет в бумажном виде — спасут только ветераны, которые смогут как в примере выше отвечать на вопросы вида «какого хрена так, а не по другому». И в итоге часто втыкаемся в состояние, когда вообще непонятно, как и куда сделать следующий шаг. И в этот момент возникает мысль переписать все к такой-то матери и сделать нормально. Машина запускается заново. Такая же история происходит на всех этажах. Хороший бизнес планирует себя на много лет вперед. Все крупные конторы имеют «план 2030-2040», понятно, что он очень условный и сто раз изменится, но из того, что я видел, при изменениях меняется и этот документ. Таким образом конторы поддерживают свой вектор развития и осуществляют преемственность лидеров. На местах же все не так круто.

Р(азработчик): почему в этом куске кода все через опу?
В(етеран труда): Ну, это потому, что чувак (которого вышибли после этого) решил, что он точно знает как.
Р: а почему у нас 5 языков программирования используется?
В: сначала мы из овна и палок сделали продукт А, а потом пришли ребята и сделали продукт Б на новых технологиях
Р: а чо это за репозиторий?
В: Ну, некоторое время назад одна из наших предыдущих команд решила переписать всю систему. С тех пор они уволились. Теперь никто больше не знает, как использовать этот проект. Поэтому мы отказались от него, он просто есть.

И приходит белый зверек. Оп, и не пригодна архитектура твоего решения под новые реалии, оп, и структуры данных и подходы к работе с ними не подходят, оп, и оказывается, что команды перестают мочь договариваться, что приводит к очаровательным сбоям вида «мы тут новую апиху заколбасили». А самое главное — рули не успевают договариваться и находить ответы на ключевые вопросы: по каким принципам мы запускаем новое и меняем старое? А что с технологиями? А кто принимает решения? а бизнес-процессы? А риски? А что делать, если что-то идет не так?

И очень быстро (sic!) становится понятно, что нужна стратегия, которая инкапсулирует большую часть ответов на эти вопросы, тем самым снизит флуктации при изменениях внешнего мира, что архитектура систем должна уметь эволюционировать, и это не только микросервисы в кубернетисах, что данные должны быть сложены так, чтобы их можно было переложить на время и поддержать изменения в внешнем мире, процессы должны быть гибкими и прочными одновременно. И все это вчера. Иначе не полетит. Уже не летит, если сравнить затраты на создание чего-то с результатами.