Чтобы справиться со своими задачами, архитекторам нужна руководящая роль. Что подразумевается под руководством? Весьма точное определение этому понятию дается в бизнес-модели по руководству и управлению ИТ на предприятии (Control Objectives for Information and Related Technology (COBIT)): «Руководство обеспечивает уверенность в достижении целей предприятия путем сбалансированной оценки потребностей заинтересованных сторон, существующих условий и возможных вариантов, установления направления развития через приоритизацию и принятие решений, постоянного мониторинга соответствия фактической продуктивности и степени выполнения требований установленным направлению и целям предприятия».
Применительно к ИТ руководство может касаться многих аспектов. Мы же хотим уделить особое внимание техническому руководству, что, по моему разумению, и является задачей архитектора. Если одной из задач, выполняемых архитектором, является обеспечение наличия технической концепции, то руководство имеет отношение к тому, чтобы обеспечить соответствие создаваемого этой концепции и участвовать в развитии концепции, если необходимо.
Архитекторы несут весьма многогранную ответственность. Они должны обеспечить наличие набора принципов, которые могут послужить руководством для разработки, а также соответствие этих принципов стратегии организации. Они должны также удостовериться в том, что эти принципы не требуют таких рабочих инструкций, которые будут в чем-то ущемлять разработчиков. Они должны двигаться в ногу с новыми технологиями и знать, когда нужно идти на разумные компромиссы. Это очень высокая ответственность. Кроме всего этого, им еще нужно вести за собой людей, то есть удостовериться в том, что коллеги, с которыми они работают, уяснили принятые решения и готовы к их выполнению. К тому же, как уже упоминалось, им нужно уделить время командам, чтобы осознать степень влияния их решений, и, возможно, даже вникнуть в создаваемый код.
Слишком большая ответственность? Конечно. Но я твердо придерживаюсь того мнения, что они должны справиться с ней самостоятельно. Чтобы частично разгрузить архитектора и уточнить концепцию, с ним вместе может работать толковая группа представителей руководства.
Обычно руководство является групповой деятельностью. Оно может осуществляться в ходе неформальной беседы с небольшой командой или — с целью широкого охвата — проводиться в форме более структурированных регулярных совещаний с формальными участниками группы. Я думаю, что именно здесь должны быть рассмотрены и при необходимости изменены те самые принципы, о которых говорилось ранее. Эту группу должен возглавлять технолог, и состоять она должна преимущественно из людей, выполняющих работу, в отношении которой осуществляется руководство. Группа должна также отвечать за отслеживание технических рисков и управление ими. Наиболее предпочтительной моделью для меня является та, в которой руководит группой архитектор, но при этом основная часть группы состоит из технологов от каждой исполнительной команды, как минимум руководящих командой. Архитектор должен убедиться в том, что группа работает, но за руководство отвечает группа в целом. Это приводит к разделению нагрузки и обеспечению более высокого уровня заинтересованности. Это также гарантирует, что информация свободно поступает из команд в группу, в результате чего принимаются толковые и осмысленные решения.
Временами группа может принимать решения, с которыми архитектор не согласен. Как в таком случае он должен поступать? Я, который бывал ранее в подобной роли, могу вас уверить в том, что это самая непростая ситуация, с которой приходится сталкиваться. Зачастую я склоняюсь к тому, что нужно соглашаться с решением группы. Я считаю, что сделал все возможное, чтобы убедить людей, но в конечном счете был недостаточно убедителен. Группа чаще всего намного мудрее индивидуума, и я не раз убеждался в том, что не прав! И представьте себе, насколько могут опуститься руки у группы, которой дали свободу для принятия решения, но в конечном счете его проигнорировали. Однако иногда я отвергал решение группы. Но почему и когда? Как выбрать линию поведения?
Вспомните, как детей учат кататься на велосипеде. Вы не можете ехать на нем за них. Вы наблюдаете за тем, как их шатает из стороны в сторону, но если каждый раз, когда вам будет казаться, что они могут упасть, вы станете поддерживать велосипед, они никогда не научатся ездить. И в любом случае они падают гораздо реже, чем вы ожидаете! Если же вы видите, что они вот-вот выедут на дорогу с интенсивным движением или въедут в ближайший пруд с утками, приходится вмешиваться. Так же, будучи архитектором, вы должны хорошо понимать, когда, образно говоря, ваша команда зарулит в пруд с утками. Вам также нужно знать о том, что, даже будучи уверенным в своей правоте и в необходимости остановить команду, вы можете совершить подкоп под собственную позицию, а также создать у группы ощущение, что у них нет права голоса. Иногда приходится смириться с тем решением, с которым вы не согласны. Понимание того, когда это нужно, а когда не нужно делать, дается нелегко, но временами оно просто жизненно необходимо.
Пребывание в роли главного лица, ответственного за техническую концепцию вашей системы и обеспечение выработки данной концепции, не означает принятия технологических решений. Это придется делать тем людям, с которыми вы работаете. В основном роль технического лидера сводится к тому, чтобы помочь команде повысить мастерство, разобраться в концепции, а также убедиться, что ее члены тоже могут быть активными участниками уточнения и реализации концепции.
Содействие окружающим вас людям в их карьерном росте может принимать множество форм, большинство из которых выходит за рамки данного повествования. Но есть один аспект, где архитектура микросервисов особенно актуальна. При работе с крупными монолитными системами у людей меньше возможностей получить повышение и чем-нибудь овладеть. А при работе с микросервисами имеется множество автономных наборов исходного кода, имеющих собственные жизненные циклы. Помочь людям получить повышение, возложив на них ответственность за отдельные сервисы, — это отличный способ посодействовать им в достижении личных карьерных целей и в то же время облегчить нагрузку на тех, кто перегружен работой!
Я твердо верю в то, что замечательные программы создают выдающиеся люди. Если заботиться только о технологической стороне дела, то можно упустить из виду более половины общей картины происходящего.
Подводя итог сказанному в данной главе, хочу перечислить все, что считаю основными аспектами, за которые отвечает архитектор развития.
• Концепция. Следует обеспечить наличие четко воспринимаемой технической концепции системы, что поможет последней отвечать требованиям потребителей и вашей организации.
• Чуткость. Нужно чутко воспринимать влияние ваших решений на потребителей и коллег.
• Сотрудничество. Нужно взаимодействовать с как можно большим числом коллег и сотрудников, чтобы стало легче определять, уточнять и реализовывать положения концепции.
• Приспособляемость. Следует обеспечить внесение в техническую концепцию изменений в соответствии с требованиями, которые выдвигают потребители или организация.
• Автономность. Нужно найти разумный баланс между стандартизацией и возможностью автономности в работе ваших команд.
• Руководство. Следует обеспечить соответствие реализуемой системы технической концепции.
Архитектор развития понимает, что справиться со своей нелегкой задачей он может, лишь постоянно поддерживая баланс. Внешние события так или иначе воздействуют на вас, и понимание того, где нужно им сопротивляться, а где — плыть по течению, зачастую приходит только с опытом. Но наихудшей реакцией на события, подталкивающие нас к изменениям, будет проявление еще большей жесткости или косности мышления.
Хотя многие советы, приведенные в данной главе, применимы к архитектору любых систем, микросервисы дают нам более широкие возможности для принятия решений. Поэтому способность успешно справляться со сбалансированностью компромиссов приобретает весьма большое значение.
В следующей главе мы воспользуемся вновь приобретенными знаниями о роли архитектора и приступим к обдумыванию путей поиска правильных границ для наших микросервисов.
3. Как моделировать сервисы
Рассуждения моего оппонента напоминают мне о язычниках, которые на вопрос о том, на чем стоит мир, отвечали: «На черепахе». А на чем тогда стоит черепаха? «На другой черепахе».
Итак, вам известно, что такое микросервисы, и, будем надеяться, вы понимаете, в чем их основные преимущества. Теперь, наверное, вам не терпится приступить к их созданию, не так ли? Но с чего начать? В этой главе будет рассмотрен подход к определению границ ваших микросервисов, что, надеюсь, позволит максимизировать их положительные качества и избежать ряда потенциальных недостатков. Но сначала нам нужно что-нибудь, с чем можно будет работать.
Книги о замыслах лучше воспринимаются, если в них есть примеры. Там, где это возможно, я буду делиться с вами историями из реальной жизни, но в то же время я пришел к выводу, что не менее полезно иметь под рукой какую-либо вымышленную область, с которой можно будет работать. В книге мы еще не раз будем обращаться к этой области, наблюдая за тем, как в ней работает концепция микросервисов.
Итак, перед нами современный онлайн-продавец MusicCorp. Совсем недавно компания MusicCorp занималась традиционной розничной торговлей, но, когда бизнес по продаже грампластинок рухнул, их усилия все больше стали сосредотачиваться на онлайн-торговле. У компании имеется сайт, и в ней зреет стремление удвоить свои онлайн-продажи. Ведь все эти iPod всего лишь дань моде (плееры Zune, конечно, лучше), и истинные музыкальные фанаты готовы ждать доставки на дом компакт-дисков. Качество превыше удобства, не так ли? Исходя из этого, можно ли говорить о каком-то стриминговом сервисе Spotify, который, по сути, может пользоваться успехом только у подростков?