Обо мне:
«Всем привет, меня зовут Артём, и я архитектор».
Архитектор я уже давно и много раз. На протяжении долгого времени проектированием каких только систем я не занимался. Сначала системы мультимедиа и ВКС, немного сетей (пока всё логично), далее комплексные проекты с инфраструктурой серверов, пользовательских устройств и прикладного ПО. Дальше резкий сюжетный поворот: проектирование аналитических и BI‑систем в специфике ИБ, резко обратно к «железу» — я главный инженер по слаботочным сетям в крупной строительной компании (гражданское строительство в части всего, что управляется токами ниже 220 В).
Наши дни: Сбер... я четвёртый год корпоративный архитектор инфраструктуры, включающей в себя слои аппаратного обеспечения, виртуализации, операционных систем, серверов приложений, прикладных шлюзов безопасности, Wi‑Fi сетей и многого другого.
Сказать, что я больше знаю, как не надо делать — ничего не сказать. Когда твой путь в архитектуру начинается не с «ванильных» принципов эджайла в разработке ПО, а с жестокой реальности «водопадных» проектов под закупку, сама концепция стратегического проектирования разбивается о сегодняшние требования рынка, федеральные законы и быстрый проектный заработок для компании. В таком проектировании внедрённый комплекс должен иметь технико‑экономическое обоснование, быть окончательным, сопровождаться уже готовой рабочей документацией и не осуждающими после внедрения косыми взглядами заказчика. И не имеет значения, разрабатываешь ты внутренний продукт или идущий на рынок, из какой предметной области этот продукт — принципы проектирования, в целом, одинаковы для любой разработки.
В Сбере у меня всё плавно начиналось с проектирования отдельных продуктов и их окружения, документирования «наследия» и проверки его на соответствие стандартам банка. Но в один момент все начало меняться, и я, «лёжа на теплом песочке пляжа» под названием «архитектура отдельных продуктов», сначала начал ощущать «брызги волн», а потом «надвигающийся шторм», рождаемый хаосом динамичного, постоянно меняющегося ландшафта банка, в котором крутилась нормативка, стандарты, методики, legacy‑системы, новые стратегии и другие вызовы.
О чём это?
Корпоративная архитектура — это именно про то, как остаться на плаву «во всём этом океане с меняющейся погодой» или «начать управлять ландшафтом, не привлекая внимания санитаров». Из архитектора в корпоративного архитектора ты превращаешься именно тогда, когда способен обеспечить управляемость изменений во вверенных областях, превращаешься из исполнителя‑проектировщика в фактор, влияющий на саму «окружающую тебя погоду». И это первый, наверное, главный тезис моего рассказа.
Мое понимание корпоративной архитектуры: это комплексная практика проектирования, планирования и управления общей структурой организации (вверенной тебе области); она должна учитывать бизнес‑цели, поддерживаться процессами, управляться инструментами (автоматизированными системами (АС) и работать с данными. Есть множество базовых практик, описывающих принципы корпоративного проектирования (например, наш банк близок к классической практике TOGAF), но все они сильно адаптированы ввиду специфики предметной области или принципов работы организации.
Нужно ли всегда применять принципы корпоративной архитектуры? Возможно, вы это делаете, не подозревая об этом. Коммерческие компании могут организовать малую связность своих внутренних процессов и прекрасно с этим жить, пока эта схема управляема. Вам не нужна единая иерархическая система, но принцип «малой связности» — тоже принцип построения корпоративной архитектуры. Эту архитектуру можно применять, например, только для организации внутренней работы головной компании, либо для управления только дочерними предприятиями, или взаимодействия с внешними заказчиками, но она может работать и в комплексе.
Здесь мы подходим к главной задаче корпоративной архитектуры: управление сложностью — это второй главный тезис статьи. Сложность у всех разная — где‑то это процессы логистики, торгов на рынках, взаимодействия филиалов, международное взаимодействие, поиск финансовой эффективности и тому подобное. Пока компания эффективно управляется локальными процессами, это управление прозрачно и в меру легко меняется, внедрение практик централизованного корпоративного управление через архитектуру не столь востребовано, чем в случаях, когда она сваливается в полную сингулярность, в которой остаётся реагировать на сложившуюся ситуацию только реактивно.
Это всё красивая теория, покажется вам, а где же тут корпоративный архитектор? Какие у него задачи и возможности? Здесь мы переходим к сути и опыту влияния корпоративного архитектора на поведение ландшафта вашей организации. Если вы выполняете комплексные проекты, дорабатываете их по требованиям «свыше» — вы обычный архитектор. Если вы меняете принципы комплексного проектирования, меняете требования самого заказчика, влияете на сложность его задач и последовательность их выполнения, а ещё влияете в какой‑то части на принципы работы всей организации — вы корпоративный архитектор.
Путь
Всё верно, основное различие — способность прогнозировать изменения, и это не какая‑нибудь магия, а вполне себе осмысленная деятельность по исключению лишних рисков, очевидных будущих ошибок и «разумно‑ленивого» подхода с целью не выполнять с продуктом в будущем ненужных бессмысленных действий.
Корпоративный архитектор — это:
«решала» насущных вопросов продуктовых команд, чьи системы он курирует;
«строитель» целевого видения продуктов или сервисов ландшафта;
«бульдозер», или инженер по разбору «завалов»;
«управляющий» правилами и принципами описания ландшафта;
«создатель» элементов стратегических изменений организации.
Да, всё это кроме самой линейной функции проектирования архитектуры, и именно в такой последовательности. Давайте объясню.
«Решала»
Под вами большая команда, где есть архитекторы сервисов, инженеры, разработчики, аналитики и просто исполнители разных рутинных задач, но, одновременно с этим, они заказчик ваших архитектурных решений, без которых им формально не дают ничего сделать. Над вами руководители Бизнеса (внутренний или внешний бизнес‑заказчик), потребители сервисов, которые диктуют свою скорость разработки, KPI. Они все требуют функциональность — они драйвер задач, и им без разницы, какие ограничения инфраструктуры и безопасности есть в организации. Ни те, ни эти вас не слушают (они вообще мало понимают, чем вы заняты, и решают принципиальные вопросы разработки без вас): команда продукта живёт в своем «эджайле», старается оперативно решать насущные проблемы и не расстраивать Бизнес, который гонится за эффективностью и презентацией новых возможностей Заказчику. Необходимо хотя бы отследить, чтобы команда не нарушила слишком много правил вашей организации. Если вы постоянно только успеваете «догонять архитектурой», зафиксировав уже принятые Бизнесом и командой продукта решения, — вы технический писатель, поздравляю, с чего‑то надо начинать, но пора что‑то менять. Команда продукта должна вас слушать, а Бизнес — советоваться. Многие корпоративные архитекторы проходят эту ступеньку, но не все идут дальше, потому что либо просто начинают командовать, либо принимают позицию догоняющего навсегда. Но мы не будем задерживаться на этом этапе и попытаемся это изменить на примере моего опыта.
Команду нужно убедить в том, что вы им полезны — такая синергия достигается участием в их жизненном цикле разработки и релизов через архитектуру. Их ограничивают требования надёжности, безопасности, сроки и избыточные требования Бизнеса, которые никак нельзя успеть сделать «ко дню рождения высокого начальника». Попытаемся:
Помочь легализовать то, что было у команды в «серой зоне», и за что они получали множество замечаний.
Помочь избежать лишних и ненужных доработок, которые крадут время у команды, и «силой архитектуры» сэкономить им ненужные движения.
Распланировать избыточные требования «бизнеса», выделить главное, снизить «градус» и прессинг на команду.
Защитить команду утверждёнными архитектурными решениями — им надо на что‑то ссылаться при выставлении приоритетов.
Бизнес надо убедить, что без ваших решений ничего не может быть реализовано, потому что за контроль принципиальных ограничений в вашей компании отвечаете вы. Да-да, это всё то, что их не интересует: какие‑то требования по резервированию и распределённости сервиса, какие‑то разрешённые порты, интерфейсы, контракты, протоколы и прочее. Инструмент тут один: разделить ответственность за нарушение работы продукта. Если Бизнес в угоду своим показателям не хочет отвечать за все риски продукта, то он должен доверить часть решений архитектуре.
И вот в какой мы интересной ситуации: команда нам начинает доверять и советоваться, потому что вы решаете их текущие проблемы, снимаете нагрузку и минимизируете сложность, а Бизнес начинает нас слушать, потому что уверен в правильности разделения ответственности. На этом шаге у вас уже начинает зарождаться дар предвидения, и как правильный «ленивый архитектор» вы хотите минимизировать количество исправлений и доработок в будущем, выполняя при этом роль балансировщика между командой и бизнесом. Если удастся найти этот баланс, то команда к вам будет приходить советоваться и получать разрешения на те или иные действия, а здесь у вас уже есть и кнут, и пряник. Бизнес при этом просто доволен, что его план работает, а риски контролируются.
«Строитель»
На этом этапе, после того, как вы благодаря своим социальным навыкам выстроили коммуникации между командой и Бизнесом, умудрившись при этом не испортить всё глубокой технической экспертизой, пришло время улучшить свои навыки магического видения будущего и запугать всех неотвратимостью грядущего! Да-да, вы знаете, что такое целевая архитектура. Вы начинаете строить будущее, не очень далёкое, но достаточно чёткое на ограниченный срок, чтобы презентовать себя как дальновидного специалиста, увеличить значение и важность архитектурного подхода, а также контроля всех решений в компании.
Из чего строится прогнозирование? Просто из добротной аналитики и фактов. Как выглядит магия? Когда ваши прогнозы сбываются.
Я не заметил, как сам начал обладать даром предвидения неотвратимости грядущего в проектировании. Внутри же всё это базировалось на простом анализе смежных факторов, которым большинство просто не уделяет и крупицы внимания в работе. Риски процессов управления продуктом, ролевые модели, масштабирование, резервирование, контроль целостности системы, технологическая платформа, программа «импортозамещения», статистика простоя, нехватка тестировщиков, перегрузка функциональностью, несоответствие внутренним нормативным документам, нехватка функциональных интеграций и припрятанные «legacy‑чемоданы» функциональности — вс§ это риски, выстроив работу с которыми и сопоставив с действующими нормами компании, вполне можно предупредить команду о готовящихся сложностях в жизни их продукта. А в плане устранения хотя бы части из этих проблем вполне можно сформулировать цель — вот она, ваша целевая архитектура на год‑два.
Для Бизнеса должны быть другие аргументы: развитие его продукта, сокращение издержек, ну и прочая эффективность, ликвидность, и... ах да, тренды! Дальше подключается перк «Решала» и прокачивается навык «дар убеждения», при помощи которых вы помогаете команде, снижая количество грядущих проблем, а Бизнесу — увеличивая перспективы.
Конечно, исходные данные — исповедь о проблемах и мечты о перспективах — на плечах команды и Бизнеса соответственно. Никакая аналитика не делается из ничего. Даже если они потом не учтут часть рисков, то со своей стороны можно будет включить архитектурный перк «я же говорил!». Так как, скорее всего, даже минимальный риск в продукте будет влиять на развитие и «подкидывать» лишние действия, не стесняйтесь об этом напоминать, в следующей итерации команда об этом вспомнит. Если какие‑то риски не будут реализованы — вы тут тоже молодец, потому что вы их нашли как возможные, и смогли «минимизировать негативный эффект», как не реализовавшиеся.
В итоге навыки «Строителя» делают из вас прагматичного архитектора, который перестраховывается только на первый взгляд. Реальность же такова, что вы своими предостережениями поможете процессу разработки стать более осмысленным, хоть и немного «душноватым».
«Бульдозер»
Вот тут начинается опасность. Ваша текущая эффективность, умение работать с типовыми и референсными решениями и опыт могут сыграть с вами злую шутку. Как правило, когда все уже знают, на кого можно положиться, на вас сваливается множество контрольных задач, экспертиза смежных решений и помощь коллегам по ландшафту. Вы начинаете распыляться, «разгребать тонны завалов» чужих задач и спасать всех вокруг, превращая своё полезное существование в рутину и теряя только что обретённый дар «предвидения». Нужно помнить, что набрав круг перспективных задач, их нужно будет потом ещё сопровождать и поддерживать, плюс различные случайные факторы, которые стремятся выбить вас из графика. Очень большая опасность вернуться на стадию «Решала», а то и в её начало, после чего перегореть и перестать вообще к чему‑либо стремиться и развиваться. Необходимо жёстко контролировать баланс нагрузки: «мёртвый корпоративный архитектор» — не архитектор, пользы от него в архитектуре и предвидении никакой. Из двух зол выбираем меньшее, так как для системного анализа в корпоративной архитектуре нужно пространство.
Я ввёл для себя правило: предупреждать руководителя о перегрузке, которая повлечёт неуспеваемость решения конкретных задач с уточнением временного отрезка. Именно такое уточнение имеет ценность в формулировке для руководителя. Да, именно это многие работники стесняются делать: «а вдруг руководитель подумает, что я недостаточно эффективен». Работает это как раз наоборот: осознание собственного предела ресурса даёт руководителю ясность вашей деятельности и понимание, что вы нацелены на результат, а также разумно и эффективно планируете свои силы.
Набрать задач и молча не справиться — вот настоящий «сотрудник‑проблема» для руководителя.
В итоге, учишься смотреть на свою загрузку хотя бы на один квартал, а лучше — на два и конец года, отсеивая необязательные задачи и держа под контролем потенциально конфликтные ситуации.
«Управляющий»
Хотите вы этого или нет, но вам придётся улучшать себе инструментарий проектирования, иначе вы «бульдозер»:
участвовать в разработке виденья и концепций продуктов;
исправлять и дорабатывать внутренние процессы и стандарты;
формулировать требования на доработку инструментов проектирования;
менять архитектурные принципы проектирования.
В общем, делать всё то, что может ускорить вам работу, уменьшить ограничения и количество шагов согласования. Мой личный опыт заставляет меня делать изменения точечными, атомарными. Всё то, что можно исправить простыми нововведениями, начинает работать гораздо быстрее. Особенно в больших организациях, где изменения вносят «пачкой», заставляя перестраивать процесс разработки архитектур и методик. Если простая доработка смогла не сломать существующее процессы и правила, и хоть немного упростить и ускорить проектирование, то это эволюция.
Как только доработки перестали работать и эффект от изменений почти «косметический» — нужна революция. Здесь придётся менять что‑то фундаментально, причём такой переход должен быть спланирован, без этого «взрывом процессов» можно получить больше проблем.
Автономность и малая связность компонентов ландшафта организации — наше всё. Казалось бы, делайте мир лучше, что вам мешает на этом этапе? — сложившаяся структура вашей организации. Вы отчаянно стараетесь быть «строителем», не свалиться в роль «бульдозера» и шагнуть ещё выше, но структура вашей огромной корпорации говорит: методиками занимаются одни люди, концептуальной, детальной архитектурой, прикладными сервисами — другие, процессами и стандартами — третьи, а стратегии так вообще не нужен никто из вышеперечисленных. Поздравляю, вас начали затягивать «серые зоны» и прочие глубины неопределённости и противоречий, о которых я говорил в самом начале. Начиная с некоторых масштабов организации всё это старается совершенствоваться самостоятельно, поэтому изменения учитывают совсем не полный перечень факторов влияния на весь остальной ландшафт.
Если ваша организация уже прошла эволюционный этап «обрастания» множеством слоёв внутренних нормативных документов(ВНД) — стандартов, процессов, методик, индексов качества и метрик, — то вы должны заметить два варианты развития:
ВНД живёт автономно, работает только в выделенной области, имеет долгий цикл изменений, чаще всего является дополнительной сложностью.
ВНД соприкасается и актуализируется совместно со смежными ВНД, развивается чаще для упрощения, ускорения или установления корреляции с другими ВНД, и, самое важное, с практической реальностью.
Корпоративная архитектура, на мой взгляд, — это не только практика проектирования и слой поддерживающего инструментария, это определения, правила, методики и ограничения. Казалось бы, всё проще, зачем придумывать столько всего описательного? Сервер есть сервер, поток данных — взаимодействие по адресу и протоколу. Но вы уже зрелая организация и имеете в структуре столько элементов управления, что не определив «на бумаге» упомянутые правила, вы свалитесь в «сингулярность», где термин «само как‑то работает, не трогай» станет обыденностью, до первого крупного инцидента, конечно. Архитекторы методик, стандартов и других принципов (да простят они меня) — отдельные корпоративные архитекторы, но если у этих людей отсутствует реальная практика проектирования «сегодняшнего дня» — «привет Вариант 1» со всеми вытекающими последствиями и сложностью для всех остальных в угоду одному показателю организации. Да, показатель нужен, наверное. Да, его требует руководство для реализации какой‑то цели, но такое нововведение тормозит множество других «разрезов» архитектуры, в результате увеличивая сложность.
При этом практикующий корпоративный архитектор самостоятельно мало способен вытянуть разработку целого ВНД. И чтобы сложился «Вариант 2», группы разработки ВНД должны приглашать тебя в рабочую группу по разработке таких ВНД, сначала хотя бы ситуативно, а лучше регулярно. Наиболее эффективно будет, если такой ВНД разрабатывают с вашим непосредственным участием или постоянной экспертизой и согласованием. Мой опыт участия в подобных рабочих группах заставлял меня всё время:
Настаивать не усложнять, а внедрять более простые методы. Если простого метода достаточно, то зачем сейчас внедрять многофакторный и сложный? — «Соберём статистику, замечания, подправим с минимальными ограничениями и количеством шагов выполнения».
Ограничивать количество внедрений новых правил. Внедряем важное, оставляем на доработку второстепенное и прочие «улучшайзинги» — «Изменения должны быть безболезненными и малозаметными».
Просить обосновать теоретическую полезность внедрения. Исключаем ситуации типа: «мы тут прочитали на Хабре про классный фрейморк и опыт его применения, вот внедряем, будем тестировать» — «А вы изначально его теоретическую полезность и применимость оценили? А может, есть инструменты лучше, или математика проще»?
Заставлять удалять старые правила. «Это наследие у нас осталось ещё с 20хх‑годов, так сложилось» — «Так если оно не нужно или только мешает, может, вывести это из эксплуатации, чтобы потенциально не конфликтовало с новыми правилами?»
Приводить контрпримеры «реальности». Как можно больше приводить методологам практических примеров, где их новые принципы могут сломаться. Если после такого анализа принцип будет внедрён без исключений или с их минимальным количеством — значит, «имеет право жить».
Поздравляю, товарищ «Управляющий» — вашей острой экспертизы боятся, но осознавшие и уверовавшие в оную — дают организации действительно эффективные изменения, подкрепленные проверкой множества сомнений и профильтрованные практикой референсных решений. Ваша критика строится на практическом опыте неудачных решений, высокой насмотренности рисков, а так же стремлении сделать решения более прозрачными, эффективными и быстро внедряемым.
«Создатель»
Важно понимать, что если вы перешли на уровень «создателя», то ни в коем случае нельзя забывать все пройденные ступеньки «решалы», «строителя», «управляющего» и, особенно, роль «бульдозера». Если такое случится, то вы тут же отрываетесь от реальной практики и больше начинаете всем мешать, а не работать в едином ландшафте. Помнить, сколько разработчиков делают одну сложную функцию или сколько прикладных архитекторов проектируют отдельные компоненты важно и нужно, так как архитектор должен внедрять решения с оглядкой на всех тех людей, чьи рабочие процессы это затронет. Необходимо все время подвергать сомнению свои достижения в части пользы.
Первые ступени развития архитектора всегда держат в тонусе, заставляют вести диалог, сомневаться, доказывать правоту, оценивать результат, но эта ступень требует куда большего. Сейчас мы подходим к сути главных тезисов: что такое проектирование в корпоративной архитектуре, и вспоминаем главные тезисы: управление «окружающей тебя погодой» и управление сложностью.
Движения не будет, если не будет новых принципов; их не будет, если вы не научитесь влиять на окружающую вас среду; а к этому вы не перейдёте, если не сможете освободить себя от рутины и не свалитесь в сингулярность. На этом этапе придётся серьёзно снизить долю типовой рутинной деятельности, пусть это будет при помощи модных ИИ, организационных преобразований, делегирования и автономности, или всё вместе взятое. Ваш опыт решения конфликтов архитектуры, широкий кругозор и глубина экспертизы в отдельных направлениях делает вас неоценимо сильнее в разработке архитектуры стратегического уровня, будь это группы продуктов, направление группы сервисов или целой платформы. Задать «моду», которая заведомо будет иметь положительный эффект, — вот ваша ценность.
Мой опыт здесь говорит мне: «держи руку на пульсе», хоть немного, но контролируй все свои направления просто для того, чтобы быть в курсе изменений. Хоть чуть‑чуть участвуя во всех процессах компании совершенно не успеваешь погружаться в отдельные вопросы, да они и не должны уже интересовать. Создать тренд, идею, концепцию или архитектурный принцип, найти незамеченные зависимости или закономерности — всё это требует широты взгляда и контроля. Глубоко можно оставаться только в своей базовой специализации, остальные подробности помогут доработать ваши коллеги-архитекторы, которые также специализируются уже на других системах, областях, технологиях.
Я стараюсь готовить свои идеи в виде предварительных материалов для обсуждения. Ох уж эти коллеги с распределённым мышлением: «давайте соберёмся и побрейнштормим».
Результат — трансформация вашей ценности в компании. Вы больше не нужны для линейной работы, вы нужны там, где задача ещё не сформулирована до конца, где нужно увидеть то, что не видят другие, где нужно исследовать и предлагать новое. Вы теперь разрабатываете новые методики, алгоритмы модели, имея опыт реального проектирования. Вы способны сразу оценить потенциально негативное и положительное влияние своего результата на окружение.
Выводы
Ваша роль — коллективный разум в одном лице (пусть даже в отдельно вверенной области). Честно сказать, я сам сделал здесь только несколько небольших беспорядочных шагов, но хотя бы видно направление и чувствуется активная позиция руководителей, которые подталкивают меня в сторону творческого аспекта корпоративной архитектуры.
Жить и пассивно принимать постоянно меняющихся вокруг тебя правила — путь, полный стресса и «боли», отстраниться от изменений не получится. Справиться с корпоративной архитектурой можно, только управляя ею и влияя на неё, на сколько хватает у вас желания и интереса. Возможность адаптироваться — это тоже навык, но сильно легче это будет делать, если правила для адаптации пишете вы сами.
Итог
А итоги слишком очевидны: хотите расти в корпоративной архитектуре — выращивайте корпоративную архитектуру. Возможно, сейчас вам хватает ступени «технического писателя» или «строителя», но внешние факторы заставят вас сделать выбор. Ещё помогает делать выбор собственная «АйТи‑лень» (или правильная лень): сделай сразу правильно, чтобы потом не переделывать (удивительно, но вокруг много примеров обратных: сделать «затычку», потом переделать).
Удивительно, но одновременно вы можете находиться в нескольких состояниях: быть «создателем» в задачах типа «никто кроме тебя»; быть «строителем» с существующими инкрементальными архитектурами; разгребать «бульдозером» переданную в авральном состоянии задачу от коллеги на время его отпуска, и так далее. Балансировать роли или существовать в одной — здесь мой опыт вам не помощник, так как это уже зависит от специфики вашей работы, ваших задач и вашей компании.
Все эти этапы взросления корпоративного архитектора, надеюсь, помогут понять, на какой ступеньке находитесь вы сейчас, что вам не хватает и хотите ли вы чего‑то большего от себя, компании и её задач.