Программируя в течение 20 лет, я очень часто слышал об архитектуре и архитекторах. При этом с архитектурой проектов работать приходилось постоянно, а живых архитекторов не видел никогда. 

Да, в командах всегда были сильные разработчики, которые следили за развитием отрасли, были жадными до новых технологий, языков программирования и баз данных. Несмотря на то что архитекторов в командах не было, книг по архитектуре хватало. IT-отрасль интенсивно трансформировалась под воздействием больших данных, docker-революции, восхождения облачных платформ. 

Разработчика всегда спрашивают: «Куда ты хочешь развиваться — в менеджмент или архитектуру?» Более того, я сам это делал множество раз :) Всегда складывалось впечатление, что на этой развилке работает только одна дорога — в менеджмент. 

В этой статье хотелось бы разобраться, откуда архитекторы взялись, какие они бывают, как трансформировалась профессия, чем они сейчас занимаются, когда без них никак, а когда они не нужны. 

Кто такие архитекторы и чем они занимаются  

Как появились архитекторы

Термин «компьютерная архитектура» ввёл в оборот Фредерик Брукс в 1970 году. Работа Брукса «Мифический человеко-месяц, или Как создаются программные системы» до сих пор считается классической.

Компьютерная индустрия по сравнению с другими инженерными отраслями считается довольно молодой. Поэтому первопроходцы заимствовали идеи из соседних инженерных направлений: электрической, электронной, строительной.

Причём «компьютерная архитектура» появилась тогда, когда произошло разделение аппаратной и программной частей компьютеров. За железо больших машин отвечал главный конструктор, а для программной части необходимо было ввести своего руководителя. Им стал «архитектор» — человек, который проектирует, координирует и осуществляет архитектурный надзор создаваемой программной системы.

Со временем стали появляться и другие типы архитекторов. Среди них нужно как минимум выделить три слоя:

• архитекторы предприятий (enterprise architect) — проектируют архитектуру всего предприятия;

• архитекторы решений (solution architect) — отвечают за связи между компонентами;

• архитекторы приложений ( application architect) — детально знают и прорабатывают сами компоненты.

Архитекторы предприятий отвечают за всё: начиная от бухгалтерии, заканчивая совместимостью различных продуктов, которыми пользуются клиенты. Если в компании большая архитектурная группа, архитектор выступает руководителем для остальных архитекторов.

Архитекторы решений отвечают за связи между компонентами и за интеграции. Очень редко для работы предприятия требуется одна монолитная система, как правило, это несколько взаимодействующих систем. Связи между этими системами лежат в зоне ответственности архитектора решений.

Архитекторы приложений отвечают за сами конечные компоненты.

Новые роли начали появляться, потому что задачи, которые стояли перед разработчиками, постоянно изменялись. Более того, они продолжают изменяться и по сей день. Выделяют data-архитекторов, сетевых архитекторов, бизнес-архитекторов, cloud-архитекторов и прочих, адаптируя эту роль под новые задачи и среды.

Как изменялся характер работ архитекторов

Характер работ архитекторов изменялся и сильно. Во-первых, архитектор всегда изучает текущий бизнес, пробует выстроить его бизнес-модель. Во-вторых, сама IT-отрасль довольно сильно изменилась. Трансформировались и архитектурные подходы. 

Если взять последние 25 лет, то можно заметить следующую особенность. Архитектурные идеи и открытия сначала становятся достоянием архитектурного сообщества. Затем они проникают в среду разработчиков. Потом они встраиваются в языки программирования, фреймворки, инструменты. Проблема, которую решают архитекторы, теряет свою остроту, и они могут заняться чем-то другим.

Звучит довольно абстрактно, поэтому пробежимся по значимым архитектурным вехам.

Возникновение объектно-ориентированного программирования (ООП) стало попыткой упростить моделирование бизнес-логики. Если мы можем при помощи ООП создать язык предметной области, тем более если он окажется единым языком с бизнесом, то написать программу на этом языке будет проще. Вместо того чтобы использовать компьютерные термины — файлы, переменные, указатели, давайте говорить в терминах бизнес-логики — пользователи, счета, документы. В такой программе будет меньше ошибок, а главное — её будет проще читать и модифицировать. А модифицировать придётся по мере исследования бизнеса: как со стороны разработчиков, так и со стороны бизнеса.

Очень скоро выяснилось, что в ООП довольно легко запутаться и написать плохую программу. В 1995 году четыре автора Гамма, Хелм, Джонсон и Влиссидес — более известные под обозначением «банды четырёх» — написали книгу «Паттерны объектно-ориентированного проектирования». Это справочник удачных приёмов использования объектно-ориентированного программирования. Такие приёмы они назвали паттернами проектирования, заимствовав термин из строительной архитектуры.

Они не собирались охватывать все возможные варианты разработки программного обеспечения и ограничились объектами, классами и интерфейсами в памяти — оперативной и, в редких случаях, на жёстком диске. При этом сразу заявили, что справочник и типизация очень ограничены и касаются только ООП в рамках памяти компьютера. Всего получилось 23 паттерна проектирования.

Также в книге они заявили, что за её пределами остаются вопросы взаимодействия с базами данных, системы реального времени, телеметрия и прочие вопросы. Дескать, если кто-то хочет продолжить создание справочников — будем рады, мы же сосредоточились только на ООП и управлении объектами в памяти компьютера.

Ценность их работы заключается в том, что они создали универсальный язык паттернов для разработчиков. При этом каждый из паттернов можно использовать независимо от языка программирования: он описывает абстрактную идею, а не реализацию в рамках какого-то конкретного языка. Паттерну назначается короткое и ёмкое название, которое удобно использовать в диалоге. 

Книга «банды четырёх» сильно повлияла на индустрию и оказалась настолько популярной, что многие идеи и паттерны были встроены в новые языки программирования и библиотеки. 

Пытаясь переосмыслить паттерны для новых программных систем, разработчики часто обнаруживают, что паттерн уже является элементом языковой среды. Значение ряда паттернов стало снижаться, по крайней мере, для современных языков программирования и фреймворков. Например, если во фреймворк уже заложена идея MVC, в собственной реализации нет необходимости: проблема разделения кода, данных и их представлений решена уже «из коробки».

Создавая книгу по паттернам, «банда четырёх» сразу задала правила игры. Например, в книге не были описаны: наследование, инкапсуляция и полиморфизм.

Если бы мы ориентировались на процедурные языки, то включили бы паттерны: наследование, инкапсуляция и полиморфизм. Снижение ценности уже реализованных паттернов было заложено с самого начала. 

Для многих разработчиков, использующих готовые фреймворки, оригинальные паттерны стали достоянием истории. Да, мы их внимательно изучаем, как источник вдохновения, мы о них говорим на собеседованиях. Но это напоминает ситуацию с алгоритмами: такое ощущение, что их спрашивают по инерции. В большинстве компаний спрашивающий и отвечающий уверены, что на практике с ними не столкнутся. Тем более, кандидат не будет вычислять синус через ряд Тейлора, он просто воспользуется готовой реализацией без проверки того, что за ней стоит. Так и с паттернами: мы доверяем реализации во фреймворке, часто даже не задумываясь о собственной реализации.

Из-за популярности книги и призыва описывать новые паттерны стали появляться новые работы. Одной из классических стала книга «Шаблоны корпоративных приложений» Мартина Фаулера.

На мой вкус, название неудачное, так как книга охватывает лишь шаблоны взаимодействия с реляционными базами данных. Однако эффект был не хуже, чем у бестселлера «банды четырёх». Именно в этой книге описаны: Domain, ActiveRecord, DataMapper, сервисы.

Фактически у нас появились инженерные справочники, универсальные наборы архитектурных решений с описаниями и рекомендациями. С паттернами этой книги произошло то же самое — они были поглощены фреймворками. 

В своей работе Мартин Фаулер признаётся, что у него обширный опыт взаимодействия с реляционными базами данных, но он не касается проблемы асинхронных взаимодействий. Эту нишу закрыла книга Грегора Хопа и Бобби Вульфа «Шаблоны интеграции корпоративных приложений». Название опять очень туманное, про себя я называю её «Шаблоны асинхронного взаимодействия». Именно в этой книге впервые систематически описаны паттерны: Channel, Splitter, Aggregator, Message Broker.

Часть этих шаблонов не потеряла актуальности, однако Message Broker был реализован в виде полноценных внешних систем вроде RabbitMQ или Apache Kafka.

Архитекторы изобретают новые или обобщают существующие подходы. Их идеи проникают в разработку и берутся на вооружение. Разработчики могут решить задачи архитекторов, не привлекая последних. Сами архитекторы могут переходить к следующей проблеме. Фактически многие их идеи подлежат автоматизации.

Архитектор не нужен там, где архитектурные идеи детально описаны в литературе, а лучше — встроены во фреймворк. Однако архитектор по-прежнему незаменим, если требуется исследование проблемы, с которой никто не сталкивался. 

Или сталкивался, но нет доступной OpenSource-реализации. В этом случае он может помочь с построением архитектуры, закрепляя свою работу архитектурными решениями (ADR — architecture decision record). Фактически такие ADR выступают как законодательство на техническом уровне компании. Они позволяют исключить несколько альтернативных реализаций и сокращают издержки.

Трудно переложить на разработку сбор функциональных и нефункциональных требований, интервью бизнес-экспертов. Но эти функции в современной практике всё чаще и чаще на себя берут системные аналитики.

Подход Domain Driven Development (DDD), введённый Эриком Эвансом в книге «Предметно-ориентированное проектирование», вообще предполагает, что все участники команды вырабатывают единый язык и вместе исследуют на нём предметную область.

Владение таким языком не предполагает, что есть посредники, переводчики или координаторы. Поэтому в современной практике часто можно встретить компании, где есть разработчики, аналитики, проджект- и продакт-менеджеры, а архитекторов нет. Их функции перераспределяются между другими участниками команды.

Что делает архитектор в новой реальности

Бизнес приходит с задачами, которые нельзя игнорировать, потому что именно так зарабатываются деньги. Деньги зарабатывают не разработчики, а бизнес. Для архитектора в первую очередь важно говорить с бизнесом и понимать, как он устроен, построить модель бизнеса и провести границы именно там, где нужно.

Задача архитектора — сделать всё, чтобы уменьшить стоимость разработки. Он должен подняться над ситуацией, посмотреть вертолётным взглядом и на разработчиков, и на тех, кто занимается бизнесом, попытаться найти модель компании и доказать, что вот так делать можно, а так делать нельзя. Доказать так, чтобы эта идея была общей и для бизнеса, и для разработчиков, а лучше всего — добиться, чтобы все разговаривали на общем языке. 

Я думаю, что архитектор — это именно роль, а не должность. Архитектор должен иметь вертолётный взгляд и не склоняться на сторону технарей. Он должен быть отдельно от технологий и не писать код самостоятельно. 

Архитектор должен быть заказчиком и стейкхолдером у технических команд, одновременно с этим взаимодействовать с целым продуктом тесным образом, понимать, какие у него есть требования и бизнес-процессы, чтобы нарезать эти бизнес-процессы в большом монолите. 

У бизнеса в РФ есть проблема: мы не знаем, что будет через три-пять лет. Это лучше, чем в 90-е, когда горизонт был сужен до полугода. Но это сильно меньше, чем на Западе или в Советское время, где планирование могло быть на 20 лет вперёд. Люди, которые занимаются унификацией, не сильно востребованы. В нашем быстро меняющемся мире ценится оперативная помощь. А архитекторы склонны к антипаттерну «аналитический паралич» — они знают свою слабость и стараются её избегать. 

Архитектура часто идёт вразрез популярным и модным гибким методологиям Agile, так как это — не тщательное многолетнее моделирование, а эксперимент с быстрой обратной связью. Пробуем идею, сверяем курс с владельцем. Если идея «заходит», то развиваем её. Если идём не туда — ничего страшного, отбрасываем, мы потратили на неё не так много времени. 

IT-здание компании никогда не будет завершено. Жизнь слишком динамичная и часто меняется, чтобы мы могли себе позволить несколько лет на разработку программной системы. Поэтому часть архитекторов меняют свою роль, уходят в техлиды или тимлиды. 

Распространение Docker, Kubernetes, облачных вычислений как минимум требуют пересмотра идей архитекторов и адаптации их под новую реальность.

Архитекторы должны постоянно наращивать свою техническую компетенцию, быть на острие. Лучше чуть-чуть смотреть в будущее, чтобы знать, что там впереди. Эдакий разведотряд в составе одного человека или группы архитекторов, которые могут идти вперёд. 

Если компания богатая, им для такого штурма ещё прилагается исследовательский RnD-отдел, который не занимается бизнес-задачами, а проводит исследования на будущее. Получается, такой небольшой научно-исследовательский отдел внутри компании. Если его нет, задача архитектора — трогать новые технологии, находить плюсы и минусы, выступать популяризатором. 

Архитекторам постоянно нужно прокачивать свои софт-скиллы. Это не всегда очевидно разработчикам, которые идут в архитектуру, потому что их привлекают сложные системы и проектирование.

Чаще же работа архитектора связана с тем, чтобы организовать людей. У нас нет машины, которая без людей сделает классный образовательный продукт. Это делают люди, но их нужно организовать. Бизнес это умеет: он знает, как управлять людьми, оптимизировать процессы. А архитектору нужно построить модель, как продукт работает. Поэтому архитектору так важно совершенствоваться не только в софт-скилах, но и в бизнес-аналитике, управлении, при этом не забывать про технологии и языки программирования.

Существуют высокоуровневые задачи, которые стоят перед бизнесом. Если ответственным за эти задачи является архитектор и эти задачи выполняются, бизнес доволен — значит, архитектор успешен. 

Как правило, от архитекторов ждут недюжинную эрудицию, способность быстро погружаться в предметную область и разбираться в ней. В конце концов, им эту предметную область предстоит моделировать.

Могут ли в компании закончиться задачи для архитектора 

Теоретически это возможно. В такие моменты можно заняться RND-исследованием. Смотреть вперёд и предлагать что-то новое. Бывают такие моменты, когда у меня есть полдня свободного времени, и тогда я что-то исследую, пишу, потом показываю ребятам.

Однако редко бывает, чтобы у архитекторов не было задач. Их довольно интенсивно используют. Чем больше компания, тем интенсивнее. Более того, приходится делегировать часть задач на команду. 

Например, у нас в Нетологии принято, что 20% времени разработчики могут тратить на рефакторинг, исследовательские задачи, и мы это время используем. Можно либо увлечь кого-то идеей, либо найти коллегу, который реализует идею в качестве pet-проекта.

Самому архитектору тоже важно быть в технологическом контексте. Сохраняется он именно благодаря программированию. Это позволяет оставаться на одной волне с разработкой, чтобы оценка задач была адекватной. Если этого не делать, разработчики не будут звать тебя в качестве третейского судьи. А архитектор часто выступает таким критическим судьёй, особенно когда возникает конфликт. Должен быть человек, который разберётся, в чём проблема, найдёт компромисс и предотвратит конфликтную ситуацию в будущем.

Из каких сфер чаще всего приходят в архитекторы  

Раньше в архитекторы приходили строго из разработки, из программистов. Их вообще рассматривали, как один из типов разработки. Сейчас всё чаще архитекторы приходят из Devops-среды или из системных аналитиков.

Такая смена источника архитекторов, когда вместо разработчиков в них идут девопсы или системные аналитики, связана ещё с некоторым разочарованием разработчиков в роли архитектора. Многие разработчики не видят пользы от этой дополнительной промежуточной роли. Перед другими часто ставят вопрос: «А куда бы вы хотели развиваться в менеджмент или в архитектуру?». Отвечая на этот вопрос, разработчики часто ложно считают, что в менеджменте общения с людьми больше, чем в архитектуре. Дескать, архитектор будет изолирован от людей и копаться в сетях, коде и железках, разрабатывать прототипы. В реальности оказывается, что общения у архитектора ничуть не меньше, чем у продакт- или проджект-менеджера. Это может отпугивать тех разработчиков, которые пришли в профессию как раз для того, чтобы как можно меньше общаться с людьми.

Когда в компании нет специального человека, который занимается архитектурой, она достаётся спонтанно тому, кто готов её на себя взять. Если у техлида или тимлида болит душа за производство, он может стать точкой притяжения для всех остальных, стать де-факто архитектором. Если тимлид слишком занят командой, архитектурные вопросы могут стать прерогативой системного аналитика. 

Как я сам стал архитектором и с чем столкнулся в своей работе  

Как я попал в EdTech архитектором и почему не разработчиком

В начале карьеры я всегда работал в маленьких компаниях, фактически стартапах. Переход в крупную организацию, численность сотрудников в которой превышает 5 000 человек, переворачивает мир разработчика из стартапа. 

Крупная компания, где я работал, активно приобретала другие предприятия. Это почти всегда сопровождалось тем, что сотрудники приобретённых компаний не уживались в новом коллективе. Мне самому удалось поучаствовать в приёмке одного из приобретённых стартапов. 

В большой компании трудно сделать что-то новое, но если что-то приобретено, оно уже не теряется. В маленьких компаниях — наоборот.

Так как мой опыт работы в небольших и крупных коллективах сильно отличался, мне захотелось поработать в компаниях средней численности, чтобы проследить и активно поучаствовать в становлении небольшой компании в крупную организацию.

Хотелось разобраться: какие трудности возникают на этом пути, как маленький коллектив их преодолевает или не преодолевает, как по мере роста компании в ней появляется необходимость во втором дата-центре или инцидент-менеджменте. Цель была не просто пассивно наблюдать, но и активно помогать в таком становлении.

Поэтому я ушёл в финтех организацию, где три года разрабатывал кредитные конвейеры с использованием микросервисной архитектуры. Только на этот раз уже внимательно следил, как растёт и меняется компания, участвовал в архитектурных комитетах, сам, выступая в качестве тимлида, растил тимлидов других направлений и даже активно помогал в создании новых отделов.

Но одно дело, когда о чём-то читаешь в книгах, другое дело, когда сталкиваешься с проблемой на практике. В архитектуре часто упоминают закон Конвея: организации проектируют системы, которые копируют структуру коммуникаций внутри этой организации. Для меня было шоком, насколько сильным может быть его действие. Например, возникает отдел, он нужен и экономит ресурсы. Однако существующий уклад организации настолько силён, что отдел за полгода просто разрывают на части и его поглощают два других отдела.

Одного инженерного видения проблемы недостаточно, нужно, чтобы такие решения принимались и защищались на уровне бизнеса — то есть на уровне реальной власти в компании.

Разобщение отделов может быть настолько велико, что они выступают как своеобразные феодальные княжества: со своими правилами игры, своими сервисами, одинаковыми по назначению, но совершенно разными по коду. Объединить это лоскутное одеяло могут только общие задачи или архитектурный надзор. Более того, в компании хватало квалифицированных и инициативных сотрудников. Мы объединялись и пробовали принимать архитектурные решения. Только они не работали, так как бизнес жил своей жизнью, а технические специалисты — своей. Из-за такой разобщённости часто возникает дискоммуникация между техническими исполнителями и бизнесом.

Например, микросервисный подход, который мы использовали, часто страдает как раз из-за того, что технические специалисты не хотят вникать в детали бизнеса, где проходят реальные бизнес-границы. Большая система распиливается на множество компонентов так, как это видится технарям.

Когда от бизнеса начинают приходить задачи, часто выясняется, что для их решения требуется переработать половину взаимодействующих сервисов.

Причина этого — неверно проведённые границы между контекстами бизнеса, они не были заложены в модель при создании микросервисной архитектуры.

При разработке программного обеспечения мы должны создать модель нашего бизнеса. Модель — это всегда приближённое описание реальности, она неточна. Без модели нельзя объяснить компьютеру, что делать, то есть написать программу. Плохо промоделируем бизнес — программа будет плохой, хорошо — программа будет хорошей.

Самое неприятное, когда программисты надеются, что бизнес им объяснит, что нужно запрограммировать, а бизнес надеется, что программисты разберутся и точно промоделируют их бизнес. Самого по себе этого никогда не бывает. 

Примерно такие мысли у меня роились в голове, когда ко мне поступило предложение стать архитектором решений в Нетологии. Первая мысль у меня была отказаться, так как весь мой предыдущий опыт говорил о том, что разработчики прекрасно справляются без архитекторов. Но по мере того как для меня раскрывалась текущая архитектура и проблемы, моё мнение менялось. 

Почему Нетологии был нужен архитектор

Нетология представляла собой два монолита на PHP и Ruby, а также некоторое количество Python-сервисов. Поверх них — монолитное JS-решение на React. PHP-монолит является legacy-решением, но его отключение затянулось на несколько лет. Также есть слой Data-аналитики, включая Apache Kafka, Apache Airflow, Spark, ClickHouse.

Монолит — неплохое решение, как правило, опирающееся на слоистую архитектуру. Более того, это лучшее средство для предотвращения феодализации команды. В монолите у команды всегда есть общие задачи. Однако монолит хорошо работает, когда у каждого слоя одна команда:

Проблема возникает, когда бизнес делит команды в соответствии со своим представлением о контестах и точках сосредоточения внимания.

В этом случае вместо команды, отвечающей за слой в монолите, появляется несколько команд со своими frontend- и backend-программистами, тестировщиками и Data-аналитиками. В этом случае команда представляет собой своеобразный колодец, прошивающий архитектурные слои. 

На бэкенде у Нетологии сейчас довольно крупный Ruby-монолит – примерно 240 000 строк кода. Его начинала делать единая команда. Сейчас она под давлением бизнеса была разделена на несколько смешанных команд: рубисты, frontend-разработчики, тестировщики. Иногда возникают конфликтные ситуации, когда кто-то либо не в том стиле пишет, либо напрямую конфликтует. Просится сервисная архитектура, когда у команды есть свой код, и она знает, что он не будет подвержен изменению со стороны другой команды.

Здесь начинает работать обратный закон Конвея, когда организация команд спущена сверху, а код остался от предыдущей структуры. Так как команды разные. Всё чаще говорят о владении тем или иным участком кода. Все хотят перейти на микросервисы, чтобы создать естественные границы команд. Очень не хотелось бы, чтобы границы новых микросервисов складывались спонтанно.

Однако делить код только по командам — не совсем удачно, потому что код подчиняется не только бизнес-правилам, но и инфраструктурным. В бизнесе нет понятия базы данных, очереди или ещё каких-то технологий, которые мы используем для программирования.

Также Нетология ставит перед собой амбициозную задачу построения WhiteLabel-решения, когда текущую систему управления обучения LMS (Learning Management System) можно использовать для франшизы или создания площадки на другом языке. Монолитное решение этому здорово мешает: проще создать всё с нуля, чем переиспользовать текущее решение и команду.

Поэтому в Нетологии действительно есть потребность в архитекторе, и мне показалось, мой опыт может быть полезен. 

Когда я пришёл в команду, моя задача была в том, чтобы попробовать сделать микросервисную трансформацию, создать модульный набор, из которого, как из Lego, можно строить LMS-систему произвольной степени сложности, как бизнесу, так и разработке.

С чем я столкнулся в работе над одним из крупнейших EdTech-проектов

В Нетологии назрела такая история, что очень долго развивалось всё в рамках одного большого сервиса, туда запихивалось много команд и доменных зон. Они уже начали мешать друг другу. Когда такое происходит, нужно провести линии разграничения между этими доменными зонами, командами и сервисами. При этом нужно им задать верные правила игры, как эти части взаимодействуют между собой.

Первая задача для нашего архитектора заключалась в том, чтобы разрезать большой монолит. Вторая — это обеспечение масштабируемости нашей платформы, внедрение различных шин обмена сообщениями, интеграция систем в наш контур, которые были вне его (например, инфраструктура аналитики). 

Мы провели серию встреч с командами и продакт-менеджерами. Поштурмовали, где можем распилить монолит, наметили несколько таких точек. Все принимаемые решения оформляли в виде рабочих предложений RFC (Request for Comments), которые после положительного голосования превращались в архитектурные решения — ADR (Architecture Decision Record). 

Прежде чем реализовывать микросервисную трансформацию, нам потребовалось развернуть и внедрить дополнительные технологии, в частности, MongoDB и Apache Kafka. Мы создали прототипы для работы с этими технологиями, и у нас стали появляться первые микросервисы. Чтобы унифицировать их структуру, сейчас ведётся работа над созданием микросервисного шасси, которое позволит разворачивать их быстрее и сразу более стандартизированными. Одновременно с этим SRE-отдел переводил инфраструктуру в Kubernetes.

За девять месяцев мы организовали механизм принятия архитектурных решений, то есть любой разработчик, и не только разработчик, может выдвигать инициативу. Она доводится до всех, все её либо принимают, либо отклоняют. Также она может остаться на уровне предложения, как часть технической летописи для следующих поколений разработчиков. 

Мы сохраняем все записи, логику, контакты обсуждающих и принимающих решение. То есть те, кто будет приходить за нами, будут видеть, как мы принимали то или иное решение. Если решение принимается, за него голосуют, и оно становится «законом». Это исключает конфликты и историю, когда неподчиняющиеся друг другу люди из разных отделов пишут по-разному и создают несовместимые друг с другом системы. Начиная с этого момента всё приводится к единому руслу, кода и ошибок становится меньше, код разрабатывается быстрее, потому что мы делаем всё в едином стиле и по одним и тем же правилам. Главное — все видят, что этот механизм работает, и начинают его использовать. 

У нас появился архитектурный комитет — процесс, в котором все команды принимают какое-либо решение по внедрению технологий. Если раньше команды могли что-то внедрять, обсуждать или не обсуждать, узнавать постфактум о чём-либо, то теперь есть понятный процесс, в котором есть ответственные лица. 

Также с архитектором мы стали лучше понимать, какие доменные зоны нам не нужно выделять в микросервисы. Выделить что-то — это хорошо, но не выделить то, что бы потом мешало, — это ещё лучше. Мы себе не выстрелили в ногу. 

Сейчас перед нами стоит большая задача по переработке финансов, объединению нашей LMS и 1C. Проект масштабный, года на два. Но с архитектором мы подходим к решению этих вопросов комплексно и можем быстро отметать неподходящие варианты, не боясь, что потом это нам аукнется.

Так ли нужен архитектор компании

Почему роль архитектора в компаниях снижается

Индустрия разработки программного обеспечения находилась и находится в состоянии постоянно меняющегося технологического ландшафта. Само понятие архитектора потеряло точность: мы не строим законченного здания. Мы не можем его построить в принципе, так как информационные системы, которые обслуживают бизнес, находятся в состоянии постоянной перестройки, изменения и адаптации. А архитектор строит законченное здание, следит за его целостностью, стилем, особенностями, бюджетом строительства и обслуживания. В ситуации, когда внешние условия изменяются и на них необходимо очень быстро реагировать, нельзя запроектировать и довести до конца конечное здание. Если мы примемся продумывать и создавать здание в течение нескольких лет, мы можем не успеть на срочные вызовы реальности. Это здание, в конце концов, может быть уже не нужно заказчику.

В начале 2000-х появились гибкие методологии разработки программного обеспечения. Их основой является диалог между бизнесом или заказчиком и разработкой. Все участники проекта ставят единую цель, действуют в рамках развития проекта и пытаются достичь эту цель, адаптируясь и меняя свою точку зрения.

Тесное взаимодействие бизнеса и разработчиков привело к снижению роли архитекторов в качестве посредников. Тем более что у архитекторов есть давний недуг: будучи технарями, они склонны замыкаться в башню из слоновой кости. Тогда как в новом agile-мире требуется открытость и частое обсуждение. И всё же это не основная причина снижения роли архитектора. 

Многие приёмы и задачи архитекторов взяли на себя участники новых гибких команд. Любой бизнес, предприятие — это сложная согласованная деятельность множества людей и механизмов. Если вы берётесь её автоматизировать или запрограммировать, вы не сможете этого сделать, пока не построите модель. 

Модель по определению всегда неточная — это лишь приближённое описание. Поэтому при разработке программного обеспечения и бизнес, и разработка пытаются постичь, что происходит вокруг и как это запрограммировать. Это процесс совместный, но часто участники стоят по разным сторонам горы, пытаясь пробить туннель друг к другу.

Гора эта называется сложностью реальности. Раньше этот туннель полностью пробивал один человек — архитектор. Сейчас команда обходится практически без него. Причём проблема может быть очень сложной, её до этого мог никто не разрабатывать. Исследование этой проблемы может идти долго, мучительно, в несколько итераций. В ходе этого создаётся программное обеспечение, которое неминуемо будет много раз перерабатываться, подвергаться рефакторингу.

Разработка программного обеспечения превратилась в совместный поиск разработчиков и бизнеса. Это стало командной работой экспертов, аналитиков, топ-менеджеров и программистов. Вместо одного архитектора, потребовалось, чтобы над проблемой работала большая группа. Далеко не факт, что работа этой группы должна управляться архитектурными решениями. А именно так бы и происходило, если бы её возглавлял архитектор.

Современные архитекторы, например, Эрик Эван, создатель Domain Drive Development, говорят о необходимости создания единого языка, на котором бы говорили разработчики и бизнес. Такой единый язык рождается в процессе исследования бизнес-задачи. 

Роль архитектора нужна компании, которая находится в процессе технологической трансформации. По моим наблюдениям, в компаниях, где архитекторы были нужны, а теперь нет, их начинают как-то по-другому называть. Они становятся заместителями технических директоров, чуть меняют сферу деятельности. Но принципиально они всё так же отвечают за какой-то крупный технологический кусок, просто под другим названием. 

Создание программных систем перестало быть задачей одного человека-координатора. Вместо этого над проблемой работает взаимодействующая группа специалистов, между которыми устанавливается взаимопонимание и разделение зон ответственности. Это решает многие проблемы, в том числе и проблему бутылочного горлышка, когда один человек становится слабым звеном. Однако это порождает рассогласования, особенно если команд много. Нам по-прежнему нужны координаторы, устанавливающие правила игры. Иначе мы будем получать несовместимые компоненты.

Каким компаниям нужен архитектор, а каким — нет 

Архитектор нужен в первую очередь компаниям, выпускающим продукт, который потом живёт независимо. Например, десктопное программное обеспечение, отчасти мобильные приложения, которые трудно обновить. Или, например, операционная система: она должна быть законченной, как должно быть закончено здание в строительстве. Ещё один пример — встроенное программное обеспечение: например, видеорегистратор могут вообще не обновлять никогда в жизни.

Архитектор нужен также там, где много команд. Допустим, одна команда в Самаре, другая — в Нижнем Новгороде, третья — в Москве, и все разрабатывают продукты для одного банка. Если их оставить без координации, могут получиться несовместимые интерфейсы или продукты. 

Архитектор или даже архитектурная группа полезны крупным компаниям с большим количеством подразделений и отделов. А вот в стартапах он не нужен, потому что вся команда как на ладони, все могут договориться, отдельный координатор для этой деятельности — это, как пятое колесо у телеги. Чем крупнее компания, тем больше требуется архитектурного надзора. Чем меньше компания, тем проще выработать архитектуру и придерживаться её в дальнейшем.

Небольшие компании могут позволить себе не моделировать ситуацию, а экспериментировать. Именно поэтому в IT-фирмах так популярны A/B-тесты. Небольшой компании могут даже не требоваться архитектурные решения, так как весь её коллектив сидит в одной комнате и принятое решение распространяется мгновенно и поддерживается всеми автоматически.

Когда я описываю ситуацию, в которой компания работает без архитектора, я не говорю, что эти задачи хорошо выполняются без него. Однако часто наблюдаю именно такую ситуацию — архитектора нет или он неформальный. В небольших компаниях идёт отказ от архитекторов, если считается, что разработчики и бизнес друг друга понимают, у них общий язык, составленный, например, при помощи системных аналитиков.

В крупных организациях, банках организуют целые архитектурные группы. 

Не всегда мы имеем право на ошибку, даже одна ошибка может стать приговором компании. Например, когда мы делаем операционную систему или программы, которые должны выглядеть в едином стиле, иметь совместимые форматы ввода и вывода данных. В такой ситуации даже небольшая оптимизация на этапе проектирования позволяет сэкономить гигантские средства. 

В этом случае подключаются архитекторы, которые заранее проектируют систему так, чтобы она работала на 100%. При этом сами архитекторы тоже могут проводить эксперименты. В отличие от маркетинга их цель — не увеличить продажи, а оптимизировать существующую систему и разработать модель.

Если есть много филиалов, и разработка идёт внутри этих филиалов — здесь уже нужен архитектурный надзор и письменные архитектурные решения. Договорённости, принятые в одной команде, не могут самостоятельно подняться выше по иерархии и спуститься в другие команды. Нужен координатор, который будет находиться над командами, собирать несоответствия, вырабатывать общие правила и доводить их до всех участников разработки. Это как раз задача архитектора.

---

Получите повышение или освойте новую специальность с курсами Нетологии:

• Системный аналитик PRO;

• DevOps-инженер;

• Системное управление процессами и командой;

• Управление рисками;

• Комплексное развитие руководителей: аналог мини-МВА.