Цікаве спостереження! Третій раз за 2 тижні потрапляю на згадку «Закона Конвея» (так званий «Conway's Law») в професійних спільнотах чи навіть в робочих зустрічах. Репостив думки Jürgen De Smet щодо цього феномену у себе в Linkedin, поділюсь і тут з вами. Але спочатку трохи теорії з першоджерел для тих, хто цю тему чує вперше:

Оригінальна стаття Мелвіна Конвея (Melvin Conway) має назву «How Do Committees Invent?» і була опублікована в журналі Datamation у квітні 1968 року (після того, як її відхилив Harvard Business Review через брак формальних доказів) (PDF оригіналу можна скачати тут)

Головна теза статті (у своїй роботі Конвей сформулював принцип, який згодом назвали законом Конвея):
«Будь-яка організація, що проектує систему (у широкому розумінні цього слова), неминуче створює дизайн, структура якого копіює структуру комунікацій у цій організації».

Популяризація: Назва «Закон Конвея» закріпилася завдяки Фреду Бруксу, який згадав цю концепцію у своїй легендарній книзі «Міфічний людино-місяць» у 1975 році.

Тепер про пост Юргена, яким хочу поділитись:


Конвей ніколи не виводив жодних законів.

У 1968 році він написав статтю, в якій описав проблему, що потребувала вирішення. У своїх висновках він закликав до організаційної гнучкості та застерігав від хибної думки, ніби «просте додавання людей автоматично підвищує продуктивність».

Але індустрія підхопила його спостереження, назвала його «законом» і використала для виправдання власної негнучкості.

Ось що я спостерігаю постійно:


Компанії читають Конвея. Впроваджують обмежені контексти (bounded contexts) з DDD. Маплять кожен такий контекст на мікросервіс. Призначають по одній команді на кожен сервіс. Називають це «Зворотним маневром Конвея» (Inverse Conway Maneuver) і страшенно пишаються собою.

А потім вони все це заморожують.

Архітектура не може еволюціонувати, бо від неї залежить структура команд. Структура команд не може еволюціонувати, бо вона залежить від архітектури. У результаті кожен клієнтський запит, який виходить за межі одного контексту, неминуче вдаряється об кордони між командами.

Конвей чітко казав: архітектура повинна еволюціонувати. «Зворотний маневр Конвея» у тому вигляді, як його практикує більшість організацій, призводить до результату, прямо протилежного тому, до чого він закликав.

В епоху прискорення розробки за допомогою ШІ це стає справжньою катастрофою. ШІ заповнює жорсткі межі архітектури таким самим жорстким кодом. Обсяг коду стрімко зростає, але межі не стають гнучкішими. Архітектура «кам'яніє» саме тієї миті, коли їй найбільше потрібна здатність до адаптації.

«Закону Конвея» можна уникнути. Компанії долають його через спільну відповідальність (shared ownership), розширення зони компетенції команд та зміщення фокуса спеціалізації — від технічних компонентів у бік клієнтських доменів.

Питання не в тому, чи відповідає структура ваших команд вашій архітектурі.
Головне питання — чи здатні вони еволюціонувати разом.