Еще в 1968 году Мелвин Конвей обнаружил, что во многих компаниях именно бизнес-менеджеры выбирают программную архитектуру корпоративных систем [1]. Позднее Фред Брукс, автор книги «Мифический человеко-месяц», назвал это наблюдение «законом Конвея». Вместе с тем многолетний опыт разработки ПО показывает, что далеко не все руководители знают закон Конвея и не читали знаменитую книгу Брукса, однако прекрасно понимают, каким образом организационная структура влияет на компанию.
Идея о том, что менеджеры будут жестко контролировать требования к ПО и его архитектуру, с точки зрения большинства программных инженеров выглядит отталкивающей — они будут возражать, заявляя, что вмешательство в их дело руководителя, не являющегося техническим специалистом, ставит под угрозу успех проекта и обрекает весь их труд на неудачу. Что касается пагубного влияния менеджеров на проекты, можно провести параллель с катастрофой шведского боевого корабля «Ваза», происшедшей в 1628 году. Его строили два года и пышно украсили в честь шведского короля того времени, который лично принимал участие в руководстве разработкой конструкции. Корабль в результате вышел чересчур высоким и тяжелым, и когда его спустили на воду, на выходе из Стокгольмской гавани он опрокинулся и затонул на глазах тысяч потрясенных зрителей [2]. Убежден, что эта инженерная трагедия вовсе не является правилом для случаев, когда руководители влияют на архитектуру ПО: менеджеры вовсе не всегда «злодеи» в этих историях, хотя это и случается. Проанализируем закон Конвея и рассмотрим, каким образом руководители влияют на архитектуру ПО.
Менеджеры как архитекторы ПО
В статье, которую Конвей опубликовал в 1968 году, высказывание, впоследствии названное «законом» его имени, звучало так: «Любая организация, которая разрабатывает систему (в широком смысле), вынуждена создавать проекты, структуры которых являются копией структуры связей организации» [3]. Впоследствии закон иронично перефразировали следующим образом: «Если над компилятором работают четыре группы, то компилятор получится четырехпроходным». Брукс в своей книге «Мифический человеко-месяц» также отмечает, что, согласно закону Конвея, организационная структура «переплетается со спецификацией интерфейса» [4]. Но ведь за формирование структуры организации отвечают менеджеры среднего и высшего звена. Другими словами, по Конвею, спецификации и архитектура разрабатываемого ПО формируются менеджерами.
Руководители влияют на архитектуру ПО, так как контролируют организационную структуру, однако связь между тем и другим не прямая. Иерархия организации состоит из групп, подгрупп и членов групп (Конвей в своей статье использовал слова «комитет», «подкомитет» и «координатор»). Работу над различными элементами архитектуры поручают группам и подгруппам. Конвей обратил внимание на то, что архитектура ПО и структура организации совпадают по причине организационных ограничений, накладываемых на возможности связи. Когда организация обширная и распределенная, отдельно взятый инженер не имеет возможности общаться со всеми остальными инженерами, иначе работа бы застопорилась. Пример, если две поддерживающие связь команды верхнего уровня, А и Б, проектируют и реализуют компоненты большой системы, то между этими двумя компонентами будет связь (например, через интерфейс программирования). Однако низкоуровневый компонент, являющийся частью архитектуры команды Б, не сможет напрямую взаимодействовать с низкоуровневым компонентом, реализованным А.
В результате архитектура системы в целом повторяет структуру связей организации. Конвей в своей публикации приводил ряд примеров, один из которых касался архитектуры компилятора: «В организации-подрядчике работали восемь человек, которые должны были реализовать компиляторы КОБОЛ и АЛГОЛ. После оценки уровня сложности задачи и затрат времени пятеро были назначены ответственными за КОБОЛ и трое за АЛГОЛ. Получившийся компилятор первого языка работал в пять проходов, а второго — в три». Другой пример, приведенный Конвеем, — о двух отделах военного учреждения, которые совместно разработали систему вооружений, чья архитектура оказалась копией структуры организации.
Мой стартап занимался системами поменьше — разрабатывал на Java инструментальные средства, в коде которых целиком мог разобраться один программист или двое. В военных организациях и крупных технологических компаниях я участвовал в разработке обширных сложных систем, которые создавались крупными распределенными командами. Как уже отмечалось, организационная структура накладывает ограничения на возможности связи. В структуре организации есть инженеры и группы, которые не общаются друг с другом просто ввиду своего места в иерархии — в этих случаях действует закон Конвея.
Есть смысл обсудить, по какой причине все команды и инженеры не общаются со всеми остальными, ведь такая возможность в теории есть — можно, например, обмениваться письмами электронной почты. Проблема в масштабе. Конвей писал: «Даже в небольших организациях есть необходимость ограничивать связь, чтобы сотрудники успевали работать». Связь масштабируется только до определенных пределов. Собрания и письма электронной почты, личные и рассылки, отнимают время и силы. Если инженер ПО будет тратить все свое время на собрания и сообщения, то на выполнение прямых обязанностей его уже не останется.
Закон Конвея на службе организации
Менеджеры среднего и верхнего звена контролируют организационную структуру и опосредованно — ограничения, которые она накладывает на связь. При этом играют роль многие факторы, в том числе размер и местонахождение команд, а также общая культура связи в организации. Но является ли влияние менеджера на архитектуру ПО добром или злом?
Ситуации, подобные случившейся с кораблем «Ваза», не должны быть нормой в случае с программными проектами. Опыт показывает, что большинство руководителей проявляют глубокую заботу об организации и стараются ее улучшить. Они очень серьезно подходят к задаче формирования организационной структуры. Они могут не знать закона Конвея и книги Брукса, но если задать им вопрос, влияет ли организационная структура на результаты работы, ответ, несомненно, будет положительным. С течением времени менеджеры корректируют организационную структуру, чтобы обеспечить лучшие результаты, в том числе проектирования архитектуры ПО.
Менеджеры допускают ошибки, и провалы проектов разработки, подобные инциденту с кораблем «Ваза», случаются. В некоторых из них виновен закон Конвея. В таблице перечислен ряд советов руководителям, помогающих избежать погружения проектов на дно.
.jpg)
Урок 1: согласуйте организационную структуру с архитектурой ПО
В свое время я работал в ВВС США на проектах крупных программных систем, обеспечивающих поддержку планирования военных операций. Военное руководство уделяет большое внимание оптимизации организационной структуры, корректируя ее на протяжении десятилетий. К решению этой задачи подходят очень серьезно. Однако такая оптимизация выполняется в соответствии с военными задачами, а не задачами разработки ПО. В военных организациях, создававших лучшие архитектуры ПО, понимали важность роли программных систем для успеха своих миссий и соответственно адаптировали организационную структуру — ее выстраивали так, чтобы обеспечить прямую связь между группами, отвечавшими за ключевые компоненты программной архитектуры.
Чаще всего проекты модернизации ПО для военных касались переноса мэйнфреймовых систем, созданных в 1960-х — начале 1970-х, на платформы UNIX или Windows. Нередко при этом приходилось переходить на новые языки программирования, инструменты и базы данных. Общей целью, как правило, была экономия затрат за счет использования более современного ПО и оборудования.
Подход, при котором проект чаще всего достигал успеха, состоял в том, чтобы как можно быстрее вводить отдельные компоненты модернизированной системы в рабочую эксплуатацию. Наша команда заменяла части старой системы одну за другой, развертывая их в гибридной среде, до тех пор, пока от прежней ничего не оставалось, после чего мы с облегчением наблюдали за тем, как мэйнфрейм выкатывают из здания. Решая проблемы рабочей эксплуатации еще на ранних этапах разработки, мы уменьшали вероятность провала проекта и параллельно вырабатывали требования к системе. Однако такая покомпонентная замена значительно ограничивала свободу планирования архитектуры — новая система должна была повторять по структуре старую.
Фактически, тогда закон Конвея использовался для улучшения результатов разработки. Новая система отлично вписывалась в существующую организационную структуру, повторяя ее каналы связи, поскольку ее архитектура не отличалась от старой. Не могу точно сказать, что именно больше всего способствовало улучшению результатов — снижение риска благодаря четкому пониманию требований рабочей системы (этому назначался приоритет) или согласование программной архитектуры с организационной структурой (в то время это не осознавалось). В любом случае, выбранный подход сработал, поскольку целью модернизации ПО было снижение затрат, а не создание новой, более эффективной архитектуры.
Урок 2: ПО не может исправить неудачную организацию
По опыту, программные проекты нередко проваливаются, когда менеджеры считают, что с помощью программных систем можно эффективно решить организационную проблему. Допустим, в компании есть ряд обособленных структур, которые сложно реорганизовать, и руководству приходит в голову идея, что можно было бы разработать программную систему, которая позволит этим структурам лучше взаимодействовать. С точки зрения закона Конвея, это крайне неудачная идея, ведь одно из его главных следствий — организационные проблемы нельзя исправить с помощью программных систем. Подобная затея обречена на провал, поскольку если команды, отвечающие за различные компоненты архитектуры, не будут вместе работать над интерфейсами или просто не справятся со своими задачами, конечная система вряд ли будет соответствовать своему назначению. Организационную структуру должны исправлять сами менеджеры.
Припоминаю проект модернизации логистической программной системы, который провалился из-за того, что в организации присутствовали обособленные структуры, не поддававшиеся изменению. Руководство потребовало, чтобы было создано программное решение, которое бы обеспечило улучшение взаимодействия и экономию затрат. Проект провалился после нескольких лет работы над ним, которая оказалась изнурительной для всех участников. Помню, как командир авиакрыла жаловался, насколько мучительными были для летчиков полевые испытания этой системы. Он очень переживал за своих подчиненных, и из-за этого негативного опыта стал предвзято относиться к программным системам в целом.
Сегодня подобные провалы происходят реже, поскольку руководители со временем корректируют организационные структуры, чтобы улучшить результаты. К тому же военное руководство сегодня гораздо лучше разбирается в разработке ПО. Помню, как в самом начале моей работы в ВВС мой командир, превосходный пилот, пришел посмотреть на свой новый офис и спросил у секретаря, зачем у него на рабочем столе телевизор — на самом деле это был компьютер. Сегодня подобное, конечно, немыслимо.
Урок 3: оптимизируйте организационную структуру и архитектуру ПО
Как и военное руководство, менеджеры в крупных технологических компаниях очень серьезно подходят к оптимизации организационной структуры — они проводят реорганизации, направленные на то, чтобы способствовать инновации или повышать надежность продуктов. И подобным образом поступают не только в крупных компаниях. Брукс пишет: «Конвей указывает, что организационная структура первоначально отражает проект первой системы, который наверняка был ошибочным. Если проект системы должен допускать внесение изменений, то и организация должна быть готова к переменам» [4]. Тем самым Брукс подчеркивает, что изменение организации может способствовать созданию лучшей программной архитектуры и получению более качественных результатов.
Реорганизации могут негативно отражаться на архитектуре ПО, если они приводят к значительным изменениям в коммуникационной структуре, — в этом случае может пострадать сопровождение крупномасштабной программной системы, функционирующей в рабочей среде. Образуется технологический долг — требуется время, чтобы привести программную архитектуру в соответствие с новой организацией. По опыту, руководители верхнего звена склонны считать жизненный цикл корпоративного ПО довольно коротким — неизбежны масштабные проекты по переработке программных систем, осуществляемые каждые несколько лет. Для меня, привыкшего к тому, что военные пользуются одной и той же системой по несколько десятков лет, это стало неожиданностью. Но и эту ситуацию можно объяснить законом Конвея — только что реорганизованная команда, оценивая систему, которая воспроизводит две части прежней организации, видит неестественность такой архитектуры, поскольку границы больше не имеют смысла, а компоненты и языки программирования двух частей различаются. Масштабные проекты по переработке необходимы, чтобы привести архитектуру системы в соответствие с актуальной организационной структурой.
Урок 4: реорганизация должна влечь за собой архитектурные изменения
Программную архитектуру нужно менять с помощью реорганизаций. Неудачным будет подход, когда реорганизации избегают, а вместо этого формируют технический комитет из руководителей верхнего звена, который лишь проводит собрания с призывами к изменению системной архитектуры, но не вносит соответствующих организационных изменений. По опыту, некоторый прогресс в этом случае возможен, но обычно таким проектам сопротивляются, а успехи достигаются лишь на уровне отдельных команд, которые становятся объектом наиболее пристального внимания технического комитета. По закону Конвея, результат в подобных ситуациях и должен быть ограниченным. Более удачный подход — предложить реорганизацию, благодаря которой будут достигнуты поставленные цели.
Вместе с тем злоупотреблять реорганизациями не стоит, иначе команды начнут тратить все свое время на переписывание имеющегося кода, стремясь гармонизировать архитектуру с организационной структурой, а инновации не будет.
***
Между законом Конвея и законом Брукса есть тесная связь — оба являются меткими наблюдениями по поводу каналов связи в организациях. Закон Брукса, напомним, звучит так: «Привнесение в проект новых сил на поздних стадиях разработки лишь отодвигает срок сдачи проекта» — это происходит потому, что с новыми сотрудниками появляются и новые каналы связи. А согласно закону Конвея, архитектура, реализуемая конкретной командой, отражает каналы связи, установившиеся в соответствии с организационной структурой.
И Конвей, и Брукс предостерегают потомков от отношения к программной инженерии как к линейному процессу. Согласно Бруксу, невозможно заменить одного инженера, работающего в течение месяца, 30 инженерами, работающими один день. Причина в том, что задачи разработки нельзя просто поделить между программистами. Согласно Конвею, предположения, которые могут быть верными для чистки картошки или укладки кирпича, ошибочны при разработке систем [3].
Итак, менеджеры оказывают огромное влияние на программную архитектуру и ничего плохого в этом нет, если подходить к формированию организационной структуры столь же тщательно, как и к проектированию программных систем.
Литература
1. Фрэнк Бушманн, Кевлин Хенни. Архитектура и скорая разработка: брак, развод или дружба? Открытые системы.СУБД. — 2013. — № 3. — С. 40–41. URL: https://www.osp.ru/os/2013/03/13035115 (дата обращения: 21.11.2022).
2. A. M. Squires, The Tender Ship: Governmental Management of Technological Change. Cambridge, MA, USA: Birkhauser, 1986.
3. M. E. Conway, How do committees invent? Datamation, vol. 14, no. 5, pp. 28–31, Apr. 1968.
4. F. P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering. Reading, MA, USA: Addison-Wesley, 1982.
Тимоти Хэллоран (hallorant@gmail.com) – инженер программного обеспечения, Google.
Timothy J. Halloran, Did Your Manager Choose Your Architecture? IEEE Software, September/October 2022, IEEE Computer Society. All rights reserved. Reprinted with permission.
