Пока что основной материал книги был сфокусирован на технических проблемах перехода к архитектуре с использованием узкоспециализированных сервисов. Но есть еще и организационные вопросы, которые также стоит рассмотреть. В этой главе речь пойдет о том, что вы на свой страх и риск игнорируете организационную структуру своей компании!
Наша отрасль производства еще сравнительно молода, и в ней, похоже, постоянно что-то обновляется. И лишь несколько основных законов выдержали испытание временем. Например, закон Мура, утверждающий, что плотность транзисторов в интегральных микросхемах удваивается каждые два года, оказался невероятно точен (хотя есть люди, предрекающие скорое замедление этой тенденции). На мой взгляд, гораздо полезнее в моей повседневной деятельности оказался другой закон, справедливый практически во всех областях, — это закон Конвея.
В статье Мелвина Конвея (Melvin Conway) How Do Committees Invent, опубликованной в журнале Datamation в апреле 1968 года, было замечено: «Организации, проектирующие системы (здесь имеется в виду более широкое толкование, включающее не только информационные системы), неизбежно производят конструкцию, чья структура является копией структуры взаимодействия внутри самой организации».
Зачастую это высказывание цитируется в различных формах как закон Конвея. Эрик С. Раймонд (Eric S. Raymond) дал краткое изложение этого феномена в книге The New Hacker’s Dictionary (MIT Press), заявив следующее: «Если над компилятором работают четыре группы, то вы получите компилятор, работающий в четыре прохода».
Доказательства
История гласит, что, когда Мелвин Конвей отправил свою статью на эту тему в журнал Harvard Business Review, редакция ее не приняла, заявив, что его утверждение ничем не подкреплено. Я же наблюдал подтверждение этой теории на практике во многих различных ситуациях настолько часто, что принял ее за истину. Но вам не нужно принимать мои слова на веру: после того как Конвей вывел эту теорию, в данной области был проделан большой объем работы. Для изучения взаимосвязанности организационной структуры и создаваемой ею системы проведен целый ряд исследований.
Организации со слабыми и сильными связями
В исследовании Exploring the Duality Between Product and Organizational Architectures (Harvard Business School) Алан Маккормак (Alan MacCormack), Джон Руснак (John Rusnak) и Карлисс Болдуин (Carliss Baldwin) рассмотрели несколько различных программных систем, которые были приблизительно классифицированы как созданные организациями со связями, имеющими либо слабый, либо сильный характер. Думаю, что в организациях с сильными связями коммерческий продукт обычно подкрепляется четкой выверенностью целей и представлений, а организации со слабыми связями хорошо представлены распределенными сообществами, разрабатывающими продукты с открытым кодом.
Проводя исследования, в ходе которых сравнивались пары схожих продуктов от организаций каждого из этих типов, авторы пришли к выводу, что организации с менее сильными связями обычно создают системы с большей модульностью и меньшей степенью связанности, а организации с более сильными связями — программные средства, обладающие меньшей модульностью.
Windows Vista
Компания Microsoft, изучая влияние своей организационной структуры на качество конкретного продукта, а именно Windows Vista, провела собственное эмпирическое исследование. В частности, исследователи проанализировали несколько факторов с целью определения надежности отдельно взятого компонента системы. После изучения ряда показателей, включая такой часто используемый показатель качества, как сложность кода, они пришли к выводу, что показатели, связанные с организационной структурой, оказались статистически наиболее значимыми оценками.
Следовательно, у нас есть еще один пример влияния организационной структуры на характеристики системы, создаваемой данной организацией.
Netflix и Amazon
Наверное, идея обязательной согласованности организации и архитектуры может быть неплохо проиллюстрирована на примере Amazon и Netflix. В Amazon довольно рано начали понимать преимущества владения командами полным жизненным циклом управляемых ими систем. Там решили, что команды должны всецело распоряжаться теми системами, за которые они отвечают, управляя всем жизненным циклом этих систем. Но в Amazon также знали, что небольшие команды могут работать быстрее больших. Это привело к созданию команд, которые можно было бы накормить двумя пиццами. Это стремление к созданию небольших команд, владеющих полным жизненным циклом своих сервисов, и стало основной причиной того, что в Amazon была разработана платформа Amazon Web Services. Для обеспечения самодостаточности своих команд компании понадобилось создать соответствующий инструментарий.
Этот пример был взят на вооружение компанией Netflix и с самого начала определил формирование ее структуры вокруг небольших независимых команд, образуемых с прицелом на то, что создаваемые ими сервисы также будут независимы друг от друга. Тем самым обеспечивалась оптимизация скорости изменения архитектуры систем. Фактически в Netflix разработали организационную структуру для желаемой архитектуры создаваемых систем.
Так что же со всем этим делать?
Итак, все доказательства, как анекдотические, так и эмпирические, указывают на то, что организационная структура оказывает сильное влияние на характер (и качество) создаваемых нами систем. Но как это понимание сможет нам помочь? Рассмотрим несколько различных организационных ситуаций и разберемся, какое влияние каждая из них может оказать на конструкцию систем.
Адаптация к направлениям обмена данными
Для начала рассмотрим простую единственную команду. Она отвечает за все аспекты разработки и реализации системы. И может часто организовывать узкоспециализированную связь. Представьте себе, что эта команда отвечает за один-единственный сервис, скажем сервис каталогов нашего музыкального магазина. Теперь рассмотрим внутреннее устройство сервиса: множество вызовов узкоспециализированных методов или функций. Как уже говорилось, мы стремимся к тому, чтобы сервисы создавались в результате разбиения системы на такие части, при которых темпы развития внутри сервисов были намного выше темпов развития между сервисами. Наша единственная команда, имея возможность организовывать узкоспециализированное общение, отлично сочетается с направлениями обмена данными в коде внутри сервиса.
Одной команде проще обсуждать предложения по внесению изменений и перестроению программного кода, и, как правило, у нее имеется высокоразвитое чувство собственности.
Теперь представим себе другой сценарий. Предположим, что вместо одной находящейся в одном месте команды, владеющей нашим сервисом каталогов, есть две команды в Великобритании и Индии. Обе они принимают активное участие во внесении изменений в сервис и при этом фактически коллективно владеют этим сервисом. Географическая разобщенность и разные часовые пояса затрудняют оперативное общение между этими командами. Они полагаются на контакты более общего плана через видеоконференции и электронную почту. Просто ли будет сотруднику команды из Великобритании уверенно выполнить небольшое перестроение кода? Издержки от общения географически удаленных друг от друга команд весьма велики, и поэтому высока и стоимость координации усилий при внесении изменений.
При увеличении стоимости координации внесения изменений случается одно из двух. Либо люди находят способы для сокращения стоимости координации и общения, либо прекращают вносить изменения. Именно последний вариант ожидает нас в случае использования объемных, трудоемких в обслуживании баз исходного кода.
Мне вспоминается один клиентский проект, над которым я работал, когда одним сервисом совместно владели две географически разделенные команды. Со временем каждая из сторон начала уточнять, какой работой она будет заниматься. Это позволило каждой из них завладеть той частью базы исходного кода, внутри которой предполагаются наименьшие расходы на внесение изменений. Затем команды вели дискуссии более общего плана о взаимосвязанности этих двух частей; фактически направление общения, ставшее возможным внутри организационной структуры, соответствовало API-интерфейсу, имеющему более общий характер, который сформировал границы между двумя половинами базы исходного кода.
Какое это имеет к нам отношение при рассмотрении того, как развивается конструкция нашего собственного сервиса? Я бы предположил, что географические границы между людьми, участвующими в разработке системы, могут стать отличным стимулом для разбиения сервиса на части и что в общем вы должны продумать возможность назначения собственником сервиса одной находящейся в одном месте команды, которая сможет поддерживать стоимость внесения изменений на низком уровне.
Возможно, в вашей организации решат, что требуется увеличить штат сотрудников, работающих над вашим проектом, открыв офис в другой стране. Тогда вам придется хорошенько подумать о том, разработку какой части вашей системы можно будет туда переместить. Возможно, это подстегнет вас к принятию решения о том, по каким стыкам выполнять следующие разбиения.
В связи с этим стоит также заметить, что, основываясь как минимум на наблюдении авторов ранее упомянутого отчета Exploring the Duality Between Product and Organizational Architectures, можно сказать: если организация, создающая систему, имеет менее крепкие связи (к примеру, она состоит из географически разобщенных команд), то создаваемые этой организацией системы будут, как правило, иметь более модульную структуру и поэтому, будем надеяться, обладать меньшей связанностью. Поддерживать в географически разбросанной организации тенденцию получения более тесной интеграции за счет того, что одна команда владеет сразу несколькими сервисами, очень трудно.
Владение сервисом
Что я подразумеваю под владением сервисом? В общем смысле это означает, что команда, владеющая сервисом, несет ответственность за внесение изменений в этот сервис. Команда должна иметь возможность свободно проводить реструктуризацию кода по собственному усмотрению, если только эти изменения не нарушат условий использования сервисов. Для многих команд права владения распространяются на все аспекты сервиса, от исходных требований до создания, развертывания и сопровождения приложения. Эта модель особенно широко распространена при работе с микросервисами: небольшой команде намного легче владеть небольшим сервисом. Возросший уровень владения приводит к росту автономности и скорости поставки. Когда одна команда отвечает за развертывание и сопровождение, это означает, что у нее есть стимул создавать сервисы, которые потом можно будет легко развернуть, то есть опасения насчет «перебрасывания чего-нибудь через забор» развеиваются, когда это что-то просто некому перебрасывать!
Конечно, это одна из тех моделей, которым я отдаю предпочтение. Она передает право принятия решений тем людям, которые могут справиться с этим лучше других, повышая тем самым эффективность работы и автономность команды, но и заставляя ее нести ответственность за свою работу. Мне приходилось видеть слишком многих разработчиков, передающих свои системы на тестирование и развертывание и считающих, что на этом их работа завершена.
Побудительные мотивы для создания общих сервисов
Мне встречалось множество команд, принимавших на вооружение модель общего владения сервисами. Я не считаю эту модель оптимальной по причинам, которые уже были рассмотрены. Но думаю, что разобраться в мотивах, побуждающих людей к выбору общих сервисов, для нас очень важно, особенно в том смысле, что это, возможно, позволит нам присмотреть для себя ряд весьма убедительных альтернативных моделей, с помощью которых можно будет решить основные проблемы людей.
Слишком большие трудности разбиения на части
Вполне очевидно, что одной из причин, по которым вам может встретиться отдельно взятый сервис, находящийся во владении более чем одной команды, будет слишком высокая стоимость разбиения сервиса, или же в вашей организации могут не видеть в этом никакого смысла. Такое часто случается при работе с большими монолитными системами. Если это самые большие затруднения, с которыми вам пришлось столкнуться, то я надеюсь, что вы сможете воспользоваться некоторыми из советов, которые были даны в главе 5. Вы также можете рассмотреть вопрос объединения команд, чтобы привести их состав к более полному соответствию архитектуре системы.
Команды разработки функций
Идея команд разработки функций, известных также как функционально ориентированные команды, заключается в том, что небольшие команды разрабатывают набор функций, реализующих всю функциональную нагрузку, которая потребуется даже при пересечении границ компонента (или даже сервиса). Цели, стоящие перед командами разработки функций, вполне обоснованны. Эта структура позволяет команде сконцентрироваться на конечном результате, гарантируя тем самым, что проделанная ими работа будет содействовать устранению ряда сложностей, возникающих при попытке скоординировать изменения, вносимые несколькими различными командами.
Во многих ситуациях команды разработки функций являются реакцией на работу традиционных IT-организаций, где структура команд выстраивается вокруг технических границ. Например, у вас может быть команда, отвечающая за пользовательский интерфейс, еще одна команда, отвечающая за логику приложения, и третья команда, работающая с базой данных. В этой среде команда разработки функций сможет оказать существенную помощь, поскольку она работает над предоставлением функциональных возможностей для всех этих уровней.
При повсеместном использовании команд разработки функций все сервисы могут считаться общими. Внести изменения в любой сервис, в любой фрагмент кода может кто угодно. В таком случае роль кураторов сервисов существенно усложняется, если только она вообще существует. К сожалению, мне редко приходится видеть работу кураторов там, где используется эта схема, и отсутствие этой работы приводит к возникновению тех проблем, о которых говорилось ранее.
Еще раз рассмотрим, что собой представляют микросервисы, — это сервисы, смоделированные по образцу не технической, а бизнес-области. И если команда, владеющая каким-либо конкретным сервисом, аналогичным образом соответствует какой-либо бизнес-области, то, скорее всего, она сможет сохранить ориентированность на клиента и разглядеть больше перспектив разработки, поскольку у нее есть целостное понимание и владение всеми технологиями, связанными с сервисом.
Могут, конечно, происходить и комплексные изменения, но их вероятность существенно снижена тем обстоятельством, что мы избегаем формирования команд по технологическим признакам.
Узкие места, касающиеся вопросов поставки
Одной из основных причин, по которым люди стремятся к переходу на применение совместно используемых сервисов, является стремление избежать узких мест в вопросах поставки программных средств. Что делать, если в отдельно взятый сервис требуется внести сразу множество изменений? Представим, что мы предоставляем клиенту возможность видеть музыкальный жанр записи во всех наших товарах, а также возможность добавления совершенно нового типа материала — виртуальных музыкальных рингтонов для мобильного телефона. Команде сайта нужно внести изменения, чтобы отобразить информацию о жанре, а команде мобильной версии приложения — поработать над тем, чтобы позволить пользователям перемещаться по перечню рингтонов, запускать их предварительное прослушивание и покупать их. Оба изменения должны быть внесены в сервис каталогов, но, к сожалению, половина команды загрипповала, а другая половина застряла на выяснении причины сбоя сервиса при работе в производственном режиме.
Избежать подобной ситуации помогут несколько вариантов, не связанных с привлечением общих сервисов. Можно просто подождать и занять команды сайта и мобильного приложения чем-нибудь другим. В зависимости от степени важности функции или того, насколько долгой предполагается задержка, этот вариант вполне может нам подойти, но может и перерасти в весьма острую проблему.
Вместо этого можно будет усилить команду каталогов, чтобы они смогли быстрее справиться с работой. Чем стандартнее будут используемые в вашей системе технологический стек и идиомы программирования, тем проще будет другим специалистам вносить изменения в ваши сервисы. Разумеется, оборотной стороной медали, как уже говорилось, будет то, что стандартизация неизменно приводит к сокращению возможностей команд по выбору наиболее подходящего решения для выполнения своей работы и может привести к разнообразным малоэффективным решениям. Если же команда находится на другой стороне планеты, реализация такого варианта может стать невозможной.
Еще один вариант заключается в разбиении каталога на отдельный основной музыкальный каталог и каталог рингтонов. Если изменение, вносимое для поддержки рингтонов, очень небольшое и вероятность того, что эта область в будущем станет бурно развиваться, совсем невелика, это разбиение может быть преждевременным. Но если функции, связанные с рингтонами, приносят прибыль в течение десяти недель, разбиение сервиса на две части с передачей владения команде мобильного варианта может приобрести вполне определенный смысл.
Но есть и еще одна модель, которая может неплохо работать в наших интересах.
Семейственный открытый код
А что, если мы приложили максимум усилий, но так и не смогли найти способа, исключающего применение нескольких общих сервисов? В таком случае вполне определенный смысл может иметь правильное внедрение модели семейственного открытого кода.
При использовании обычного открытого кода его исполнителями являются немного людей. Они же являются кураторами кода. При желании внести изменения в проект с открытым кодом вы либо обращаетесь к одному из исполнителей, чтобы он внес для вас эти изменения, либо вносите изменения самостоятельно и отправляете исполнителям запрос на их прием. Основные исполнители по-прежнему несут ответственность за исходный код и являются его владельцами.
Эта же схема может неплохо работать и внутри организации. Возможно, те люди, которые изначально работали над сервисом, больше не входят в одну команду и теперь разбросаны по всей организации. Но, если у них еще есть права исполнителей, их можно найти и попросить помочь, возможно вступив с ними в сотрудничество, а если у вас уже есть подходящий инструментарий, исполнителям можно отправить запрос на его прием.
Роль кураторов
Нам хочется, чтобы наши сервисы были практичными. Хочется, чтобы код был высокого качества и сам сервис проявлял некую последовательность при сборе всего в общее целое. Мы также хотим убедиться в том, что изменения, вносимые сейчас, не затруднят внесение намечаемых на будущее изменений сверх допустимого. Это означает, что внутри нашей организации необходимо применять те же схемы, которые используются в обычном открытом коде, то есть выделить группу надежных исполнителей (основную команду) и ненадежных исполнителей (людей, не входящих в команду предлагающих изменения).
Основная команда должна иметь способ проверки и утверждения изменений. Нужно убедиться в идиоматической согласованности изменений, то есть в том, что они следуют общим принципам программирования остального кода. Следовательно, людям, выполняющим проверку, приходится тратить время на работу с теми, кто вносит предложения, чтобы убедиться в достаточной качественности вносимого изменения.
Хорошие контролеры проделывают в связи с этим большой объем работы, общаясь непосредственно с теми, кто вносит предложения, и поощряя их хорошие поступки. Плохие контролеры могут воспользоваться своим положением для демонстрации власти над другими или ведения мировоззренческих сражений вокруг произвольных технических решений. Будучи свидетелем обеих форм поведения, хочу сказать только одно: в любом случае на это тратится определенное время. Когда кураторы позволяют ненадежным исполнителям отправлять свои изменения в ваш исходный код, вам нужно решить, стоит ли беспокоиться об издержках на использование контролера — о том, может ли основная команда заняться чем-нибудь более полезным, чем проверка исправлений или изменений.
Зрелость
Чем менее стабильным или зрелым является сервис, тем труднее будет позволять людям, которые не входят в основную команду, присылать исправления или изменения. Пока не сформируется основа сервиса, команда может не знать, как отличить хорошее от плохого, и поэтому стремиться к тому, чтобы узнать, на что должно быть похоже дельное предложение. На этом этапе сервис подвергается значительным изменениям.
При ведении большинства проектов с открытым кодом предложения от широкой аудитории ненадежных исполнителей стараются не принимать до тех пор, пока не будет сформировано ядро первой версии. В вашей организации также есть смысл следовать этой модели. Если сервис уже достаточно зрелый и редко подвергается изменениям (таков, к примеру, сервис покупательской корзины), возможно, настало время открыть его для внесения предложений от других сотрудников.
Инструментарий
Для поддержки модели семейственного открытого кода на самом высоком уровне требуется наличие соответствующего инструментария. Важную роль играет использование средства распределенного управления версиями с предоставлением людям возможности отправки запросов на внедрение кода или чего-либо подобного этому. В зависимости от размеров организации может также понадобиться инструментарий, позволяющий обсуждать прохождение запросов на исправления и изменения, в котором может подразумеваться, а может, и нет, наличие системы полномасштабного обзора кода, но наибольшую пользу может принести возможность выставления встроенных комментариев по поводу исправлений. И наконец, нужно максимально облегчить исполнителю создание и развертывание вашего программного средства и сделать его доступным для других исполнителей. Обычно под этим подразумевается наличие четко определенных конвейеров сборки и развертывания и централизованных хранилищ артефактов.
Ограниченные контексты и структуры команд
Как уже упоминалось, мы намечаем границы сервисов вокруг ограниченных контекстов. Из этого следует, что нам нужно, чтобы команды также были увязаны с ограниченными контекстами. Такая увязка дает массу преимуществ. Во-первых, команде будет проще усвоить понятия в выделяемой ей области внутри ограниченного контекста, поскольку они будут связаны между собой. Во-вторых, сервисы внутри ограниченного контекста, вероятнее всего, будут общаться друг с другом, упрощая тем самым устройство системы и координацию выпусков. И в-третьих, с точки зрения взаимодействия команд поставки с заинтересованными лицами упрощается налаживание командой хороших взаимоотношений с одним или двумя специалистами в данной области.
Осиротевшая служба?
Что можно сказать о сервисах, которые больше не имеют активного сопровождения? Поскольку мы движемся в направлении использования узкоспециализированных архитектур, сами сервисы становятся меньше. Как уже говорилось, одной из целей уменьшения сервисов является их упрощение. Менее сложные сервисы с меньшим количеством функций долго могут не нуждаться в изменениях. Рассмотрим довольно скромный сервис покупательской корзины, предоставляющий ряд весьма незатейливых возможностей: положить в корзину, убрать из корзины и т. д. Вполне вероятно, что этот сервис не потребует внесения изменений в течение многих месяцев после написания даже притом, что приложение продолжает активно развиваться. И что с ним случится? Кто владеет этим сервисом?
Если структуры команд увязаны с ограниченными контекстами организации, значит, даже сервисы, не требующие частого внесения изменений, имеют де-факто своих владельцев. Представим себе команду, сформированную в соответствии с контекстом потребителей веб-продаж. Она должна заниматься сервисами сайта, покупательской корзины и рекомендаций. Даже если сервис покупательской корзины не менялся месяцами, вполне естественно, что изменениями в нем займется эта команда. Одно из преимуществ микросервисов выражается, конечно же, в том, что при необходимости изменить сервис, чтобы добавить в него новое свойство, перезапись сервиса не должна занять слишком много времени даже для команды, не испытывающей особого рвения.
Тем не менее если за основу был принят разноязычный подход, предполагающий использование нескольких технологических стеков, то сложности внесения изменений в осиротевший сервис могут усугубиться, если в вашу команду больше не входят специалисты нужного профиля.
Конкретный пример: RealEstate.com.au
Основной бизнес компании REA связан с недвижимостью. Но он включает несколько различных аспектов, каждый из которых работает как отдельное направление бизнеса (LOB). Например, в одном направлении бизнеса занимаются сделками с жилой недвижимостью в Австралии, в другом — коммерческой недвижимостью, а третье может иметь отношение к одной из внешних бизнес-задач компании REA. У этих направлений бизнеса имеются IT-команды (или подразделения) поставки, причем у некоторых направлений может существовать только одно подразделение, а у самого крупного их четыре. Итак, на направлении жилой недвижимости несколько команд занимаются созданием сайта и перечня услуг, чтобы позволить людям просматривать собственность. Бывает, что специалисты переходят из одной команды в другую, но обычно долго определенное направление бизнеса не покидают, гарантируя тем самым компетентность в данной части бизнес-области. Это, в свою очередь, способствует общению между различными заинтересованными лицами и командой, поставляющей им те или иные функции программных средств.
Ожидается, что каждое подразделение внутри направления бизнеса несет ответственность за весь жизненный цикл создаваемых им сервисов, включая создание, тестирование и выпуск, поддержку и даже вывод из эксплуатации. Основная команда службы поставок выдает рекомендации и указания этим командам, а также разрабатывает инструментарий, помогающий выполнять их задачи. Ключевым положением является культура автоматизации, и в REA широко используется AWS как основная составляющая, повышающая автономность команд. Порядок работы всего этого механизма показан на рис. 10.1.
С работой бизнеса увязывается не только организация поставок. Увязывание распространяется и на архитектуру. Примером могут послужить методы интеграции. Внутри направления бизнеса все сервисы вольны обмениваться данными друг с другом любым подходящим для них способом в соответствии с решениями подразделений, выполняющих роль их кураторов. Но весь обмен данными между направлениями бизнеса предписано вести путем обмена пакетами в асинхронном режиме, что является одним из немногих железных правил весьма небольшой архитектурной команды. Этот обмен данными, имеющий более общий характер, соответствует такому же разностороннему обмену данными, который практикуется и между различными частями бизнеса. Благодаря настоятельному требованию ведения пакетного обмена между направлениями каждому направлению бизнеса предоставляется широкая степень свободы действий и самоуправления. Им разрешено удалять свои сервисы по собственному усмотрению, и пока они могут поддерживать пакетную интеграцию с другими частями бизнеса и с заинтересованными лицами, никого это волновать не будет.
Рис. 10.1. Общее представление о структуре организации Realestate.com.au и ее команд, а также об увязке с архитектурой
Эта структура позволяет добиться высокой автономности не только команд, но и различных частей бизнеса. Начав с совсем небольшого количества сервисов несколько лет назад, REA теперь обладает сотнями сервисов, количество которых превышает количество сотрудников и растет высокими темпами. Возможность поставки изменений помогла компании добиться значительных успехов как на местном рынке, так и за рубежом. И что отраднее всего, из разговоров с людьми я вынес впечатление, что существующее состояние как архитектуры, так и организационной структуры сформировалось благодаря самым последним шагам на этом пути, но никак не достижению конечного пункта назначения. Я полагаю, что в ближайшие пять лет облик REA снова претерпит существенные изменения.
Организации с адаптивностью, достаточной для изменения не только системной архитектуры, но и организационной структуры, могут получить огромные преимущества в сфере повышения автономности команд и сокращения времени вывода на рынок новых свойств и функциональных возможностей. REA не пребывает в вакууме, а является одной из множества организаций, реализующих подобную системную архитектуру.
Закон Конвея наоборот
До сих пор речь шла о том, как организационная структура влияет на устройство системы. А как насчет обратного влияния? То есть может ли устройство системы изменить организацию? Несмотря на то что я не смог найти столь же убедительных доказательств идеи о том, что закон Конвея работает и в обратном порядке, периодически мне приходилось сталкиваться с этим явлением.
Наверное, наилучшим примером был клиент, с которым я работал много лет назад. В те дни, когда Всемирная сеть только зарождалась, а Интернет воспринимался как нечто поступающее на гибком диске компании AOL через входную дверь, эта компания представляла собой довольно солидную издательскую фирму, у которой был небольшой, весьма скромный сайт. Это был сайт ради сайта, и, по большому счету, порядок, в котором работал бизнес, был совершенно неважен. Когда была создана исходная схема, порядок работы системы строился на весьма произвольных технических решениях.
Содержимое для этой системы обеспечивалось несколькими способами, но основная часть поступала от третьих лиц, размещавших объявления для всеобщего обозрения. Была система ввода информации, позволявшая третьим лицам за плату создавать содержимое, центральная система, получавшая данные и улучшавшая их различными способами, и система вывода, формировавшая окончательный вид сайта.
Вопрос о том, были ли исходные конструкторские решения правильными на то время, мы оставим для историков, но за многие годы в компании не происходило существенных изменений, и я и многие мои коллеги удивились бы, если бы устройство системы подошло для нынешнего состояния компании. Физический печатный бизнес организации существенно сократился, а преобладают доходы и, следовательно, бизнес-операции из интернет-сферы.
Все это время мы наблюдали, как организация четко подстроилась под систему, разработанную сторонними специалистами. Три канала или подразделения, присутствовавшие в IT-сфере бизнеса, были увязаны с каждой из сторон бизнеса: вводом, ядром и выводом. Внутри каналов были выделены команды поставки. В то время я не понял, что эти организационные структуры не предшествовали устройству системы, а фактически сформировались вокруг этого устройства. По мере сокращения физической стороны бизнеса и роста его цифровой стороны устройство системы ненароком указало путь роста самой организации.
В итоге мы поняли, что, несмотря на имеющиеся недостатки в устройстве системы, для перехода в новое качество понадобилось внесение изменений в структуру организации. Сколько лет прошло, а этот процесс все еще не завершен!
Люди
Неважно, как это выглядит на первый взгляд, но проблема всегда в людях.Джеральд Вайнберг (Gerry Weinberg). Второй закон консалтинга
Следует признать, что в среде микросервисов разработчику труднее думается о написании кода в собственной ограниченной области. Он должен больше вникать в последствия вызовов, пересекающих границы сетей, или последствия сбоев. Мы также говорили о том, что с микросервисами проще испытывать применение новых технологий — от хранения данных до языков программирования. Но для тех, кто попал в мир микросервисов из мира монолитных систем, где большинству разработчиков приходится использовать один язык, совершенно не обращая внимания на оперативные интересы, такое положение вещей может стать толчком к внезапному пробуждению.
Точно так же может стать обременительным принуждение команд разработчиков к повышению автономности. Люди, которые в прошлом перебрасывали свою работу кому-то еще через забор, привыкли выдвигать обвинения в чужой адрес и не могут почувствовать себя комфортно, когда несут за свою работу полную ответственность. Могут быть даже выработаны условия контракта, предписывающие вашим разработчикам ношение приборов оперативного оповещения о сбоях в работе систем, которые они поддерживают!
Хотя эта книга посвящена в основном решению технологических вопросов, людей нельзя сбрасывать со счетов, ведь речь идет о людях, которые создали то, чем вы пользуетесь сейчас, и создают все, что будет применяться в дальнейшем. Если придумывать, как все должно делаться, без учета мнения персонала или людских возможностей, то это, скорее всего, не приведет ни к чему хорошему.
Что касается данной темы, то у каждой организации имеется свой ход развития. Нужно понимать, насколько ваш персонал готов к изменениям. Не нужно их подталкивать сверх всякой меры! Вероятно, на короткий период времени у вас по-прежнему будет отдельная команда, занимающаяся поддержкой клиентов или разработкой, что даст разработчикам время на то, чтобы подстроиться под новые инструкции. Возможно, придется смириться с тем, что для выполнения всей этой работы потребуются люди различных наклонностей. При любом подходе нужно понимать, что в мире микросервисов следует четко определять зоны ответственности людей, а также понимать, почему именно такие зоны ответственности играют для вас важную роль. Это может помочь вам заметить возможные квалификационные пробелы и подумать о том, как их заполнить. Для многих людей это путешествие станет весьма непростым. Всегда нужно помнить о том, что без людей, с которыми вы работаете, любые изменения, которые захочется внести, с самого начала могут быть обречены на провал.
Резюме
Закон Конвея подчеркивает опасности попыток навязывания моделей систем, не соответствующих структуре организации. Он подводит нас к стремлению закрепить владение микросервисами за командами, расположенными в одном месте, которые, в свою очередь, выстраиваются вокруг соответствующих ограниченных контекстов, существующих в организации. Если такая двойная увязка отсутствует, мы получаем точки напряженности, рассмотренные в данной главе. Признавая связь между этими двумя понятиями, мы сможем гарантировать наличие смысла создаваемой нами системы для заказавшей ее организации.
Часть рассмотренных здесь вопросов имела отношение к сложностям работы с расширяющимися организациями. Но есть и другие требующие рассмотрения технические вопросы, которыми следует заняться, когда системы начинают расширяться, выходя за рамки нескольких обособленных сервисов. К их рассмотрению мы приступим в следующей главе.