Привет, Хабр! Я — Светлана Уварова, ведущий системный архитектор в МТС.
В своей работе несколько раз сталкивалась с тем, что мои коллеги — разработчики, аналитики, тестировщики — не понимали, чем занимается IT-архитектор. Ведь и без него можно запустить систему. Аналитики соберут требования, разработчики воплотят их в коде, тестировщики проверят. Ну а руководитель будет отвечать за дальнейшую судьбу этого коллективного детища.
Но что, если в эту систему ворвется архитектор? В чем его задачи? Заходите под кат, обо всем расскажу. А потом отправляйте пост коллегам, если они пока не понимают, чем вы занимаетесь в команде.
Бывает, что архитектор приходит в новую команду и коллеги встречают его прохладно. Ведь и раньше без него они жили нормально. Например, мой случай: я пыталась собрать информацию о системе, а со мной отказывались общаться: боялись, что я наврежу проекту. Я предлагала решения, ставила задачи, а коллеги говорили, что они лучше знают систему и технологии, и им не нужен кто-то новый. Уходили часы на объяснение своей роли и отстаивание задач. На притирку с этой командой ушло три месяца.
Чтобы команда доверилась новому архитектору, руководитель и коллеги-разработчики должны понять роль архитектора в команде. Дальше разберу несколько мнений, которые я чаще всего слышала о своей работе.
Мнение 1. Архитектор — это технический писатель. А значит, пусть записывает то, что ему скажут
«Основной артефакт, который производит архитектор, — это документ с текстом. Если человек новенький в команде, то систему он не знает. И может записать только то, что ему продиктуют. А если записывает за кем-то, то это технический писатель».
Что на самом деле
Вся суть — в содержании и предназначении архитектурных документов. Архитектор проектирует новую систему, опираясь на то, что ему рассказали об уже работающей системе. И он старается ровно и аккуратно встроить дом «новая функция» в давно отстроенный и сданный квартал «существующая функциональность».
Нюансы
Например, в системе уже есть функция чтения доступных для покупки товаров, реализованная по одному методу. Пусть это будет метод 0. В системе указаны идентификаторы товара, иначе метод не работает: вот у нас есть хлеб, молоко, яблоки. Но не указана цена на продукцию, а по новым требованиям она должна быть. Нужно принять решение:
Доработать или изменить существующий метод, чтобы он забирал из базы данных цену и отображал ее. Назовем этот вариант метод 1.
Выпустить новую версию метода. Берем весь код прошлой версии, добавляем немножко нового кода — и вуаля! Вы прекрасны, а цена отображается. Назовем этот вариант метод 2.
Разработать совсем новый метод. Пусть он будет методом 3.
А еще есть системы, которые используют код для чтения информации о товаре с идентификатором, то есть они работают с методом 0. Например, витрины интернет-магазина, приложения, маркетплейса. И все их нужно оповестить, что метод доработан и нужно использовать его. Но системы должны научиться принимать ответ от обновленного метода.
Если мы получили метод 1 или метод 3, то все обращавшиеся к методу 0 системы придется доработать. Иначе все эти витрины сайта или приложения просто не будут знать, как принимать изменившийся ответ с ценой. Тогда вместо отображения ценника мы будем получать ошибку.
Есть вариант проще — выпустить новую версию старого метода, то есть получить метод 2. И, например, часть систем будут быстро доработаны и станут отображать цену, а часть (например, где не хватает ресурсов) будут работать на старой версии. Но ошибок не будет ни у кого из них.
Архитектор выбирает самый простой вариант с обновлением версии. Значит, в документации пишем, что разрабатываем новую версию, обосновываем решение и объясняем, чем она отличается от старой. Но для этого нужно выяснить, как выглядит старый метод.
Итог
Архитектор расспрашивает об уже имеющихся функциях системы для качественного проектирования новой функциональности. А вовсе не для того, чтобы просто записать за кем-то информацию о том, что уже реализовано.
Мнение 2. Не пишешь кода — не суйся в задачи
«Архитектор не сможет объяснить задачу разработчику, потому что он не пишет код сам».
Что на самом деле
Приведу простую аналогию — координатор по организации свадеб. Будущие молодожены могут и сами разобраться, как организовать свою свадьбу: расписать тайминг, оформить welcome-зону, выбрать напитки, собрать плейлист и так далее. Но гораздо проще обратиться к координатору: он учтет пожелания, но предусмотрит нюансы, о которых пара может не знать, и предложит лучшие решения, возьмет на себя логистику, организацию и сам проконтролирует исполнителей. Молодоженам не придется отвлекаться на несколько задач одновременно, и они смогут радоваться своему празднику.
То есть координатор знает, как лучше организовать праздник, какую команду задействовать, как распределить задачи и как их контролировать. При этом ему необязательно самому фотографировать гостей, стоять за диджейским пультом или наливать гостям коктейли — хотя вполне возможно, он это все умеет. В общем-то, архитектор — это такой же свадебный координатор, только от мира IT.
Например, в документации архитектор описывает требования, которые должен реализовать разработчик, и декомпозирует их: описывает желаемый результат, команды для реализации требований и так далее. При этом он не говорит, какие именно строки кода написать, а указывает алгоритмы и методы. Конкретная реализация — это уже задача разработчика.
Нюансы
Перечислю малую часть задач, которую выполняет архитектор:
Выбирает технологии и архитектурные подходы, особенно если разрабатывается новая система. Выясняет огромное количество нюансов. Например, разрешены ли выбранные технологии законодательством, позволяют ли они обеспечить нефункциональные требования? Микросервисы или монолит? Реляционная база данных или нет? Что важнее — быстрое чтение или быстрая запись именно для этой конкретной системы и задачи? Нужна ли интеграция, и если да, то какая?
Определяет категории данных, которые будут обрабатываться в системе. Ему нужно понять, не попадают ли они под регулирование законодательством, не требуются ли дополнительные интеграции с государственными информационными системами. Например, архитектура систем, обрабатывающая персональные данные, существенно отличается от архитектуры общедоступного развлекательного портала.
Выбирает подходы, которые обеспечивают доступность и отказоустойчивость системы.
Определяет контексты — внешние взаимодействия с проектируемой системой или новой функциональностью.
Чтобы решать все эти задачи, проектировать возможные решения и выбирать из них оптимальное, огромный опыт программирования не нужен. Хотя я сама писала на разных языках программирования много лет.
Что важно для архитектора:
Уметь выделять проблему. Расспрашивать заказчика, формулировать, уточнять, действительно ли проблема такая. И недаром говорят, что хорошо сформулированный вопрос — это половина ответа. Были случаи, когда заказчик описывал с моей помощью проблему и сам понимал, как он ее может решить без доработок. Еще один бонус от такого общения: автор запроса понимает, что его проблему разделяют, и становится лояльнее.
Уметь принимать решения. Как? Представим, что у нас есть задача. Сперва архитектор ищет десятки решений — 15, 20, 40 — сколько получится. Самое главное — все эти решения должны быть рабочими. Потом он смотрит на требования и из множества вариантов выбрасывает те, что точно не подойдут. Редко бывает, когда решение идеальное и явно правильное. Основные критерии — это выполнение функциональных и нефункциональных требований. Например, не выполняются требования по информационной безопасности — вариант сразу отправляется в корзину. А над какими-то требованиями можно подумать, поискать компромиссы. Как правило, человек, который принимает решение, соглашается с минусами. Поэтому из оставшихся условно подходящих решений надо выбрать то, с минусами которого мы сможем жить.
Уметь обосновать решение команде. Рассказать про все плюсы и минусы, объяснить, почему этот вариант лучше, чем другие 5-10-20. В 95% случаев команда соглашается. А с остальными 5% есть два пути. Первый путь — просто смириться, что есть недовольные. Особенно, если это не влияет на ваше решение. И здесь мы видим еще одно важное качество архитектора: признавать за другими людьми право на свое мнение.
Если эти люди могут повлиять на решение, как, допустим, архитектор кластера, то есть второй путь — пытаться отстоять свою позицию. Ведь именно тот, кто прорабатывал решение, больше всех остальных погружен в него. Но если аргументы оказались бессильны, то смиряемся с тем, что решение завернули и нужно выбрать другой вариант. В моей работе были ситуации, когда я считала, что выбранное решение — полная ерунда. Но, допустим, у команды сжатые сроки и придется делать вот так, а не иначе. Я могу ворчать в сторону этого решения, но принимаю его.
Иметь широкий кругозор технических знаний и пользоваться им. Тут и основные паттерны проектирования, и технологический стек — как внутри компании, так и во вне, у конкурентов, в целом на рынке. Архитектор должен быть эрудирован с точки зрения профессиональных знаний. А в этом помогают и книги, и статьи, и профильные конференции, и митапы. Самый ценный источник информации — это коллеги и их опыт. Но мало собрать информацию — нужно еще и выделить основу решения.
Приведу пример из работы с архитектурой телекома. Я занимаюсь сервисным каталогом. Его задача — описать сервисы. Что такое описание сервисов и почему это важно, я рассказывала в своей прошлой статье. Итак, если я просто сделаю информационную систему сервисных каталогов, она будет прекрасно описывать сервисы, но ничего не даст компании. Потому что компании нужно эти сервисы продавать, физически обеспечивать подключение этих сервисов на оборудование, считать факты потребления этого сервиса с конкретной минуты, секунды.
Костяк решения, на которое мы смотрим, такой:
Чтобы продать, надо описать, что мы можем продать.
То, что мы описали, мы должны уметь подключить на оборудование.
То, что мы подключили, мы должны уметь посчитать.
Если мы сделали все это, остальные функции можно уже наложить на основу, но не наоборот.
Итог: чтобы проектировать архитектуру, совсем необязательно самому писать код.
Мнение 3. Архитектор не должен заботиться о том, какими данными наполнят систему
«Зачем архитектору знать о данных, которыми будет наполняться система? Ведь для него нет никакой разницы!».
Что на самом деле
Обычно знания о данных влияют на архитектуру системы. Особенно если мы говорим о персональных данных, медицинской информации, банковских сведениях.
Архитектура системы, обрабатывающей персональные данные, будет сложной и защищенной, с функцией аутентификации и авторизации. Общедоступному сайту с рассказами это все не нужно. А если проектируемая система — преемница другой, то нужно проработать миграцию данных. И при необходимости синхронизацию — если какое-то время будут работать и старая, и новая системы вместе.
Все это, разумеется, влияет на архитектуру.
Нюансы
В этом варианте абсолютно всем пользователям разрешено все: любые данные можно изменить, удалить, добавить. Можно представиться кем угодно и делать все что захочется, подтверждения личности не требуется. Обычно это бесполезные приложения с мусорными данными и непродуманной архитектурой.
А вот в этом варианте уже придется пройти аутентификацию, ввести пароль и доказать, что «я это я». Хотя, как известно, «я бывают разные».
Пользователи имеют свои роли и, соответственно, доступы. Например, записывает данные только оператор, а читают все. И уже не получится притвориться другим пользователем — если, конечно, не знать чужой логин и пароль.
В этом варианте системы появляется брокер сообщений. Одна система оповещает другую, что ее данные изменились.
Объясню на примере. Есть справочник единиц измерения внутри компании. Если каждый филиал будет вести свой отдельный справочник, то информация может не совпадать. Например, в одном справочнике СМС указаны в штуках, а в другом — именно в СМС, мегабайты где-то обозначены как MB, где-то — МБ или Мб. И один филиал ведет справочник в виде таблицы в Excel, другой — в товароучетной системе, третий — еще где-то. Из-за этого найти информацию сложно. Чтобы данные везде записывались одинаково, есть общие справочники компании. И их заполняет, например, один отдел в мастер-системе. И как только что-то изменилось в этом всеобщем справочнике, мастер-система через брокер сообщений передает по филиалам информацию, и справочники обновляются везде.
Итог
Архитектура напрямую зависит от данных, обрабатываемых в системе. Когда вновь пришедший архитектор расспрашивает о модели данных, процессах с ней, категориях защиты, он уточняет «фундамент», на который впоследствии лягут новые функции.
Мнение 4. Архитектор = аналитик
«Архитектор и аналитик занимаются одним и тем же». Не скажу, что они на 100% не правы, но есть один нюанс. Сейчас объясню.
Что на самом деле
Аналитик отвечает за функциональные требования. Он говорит, что нужно сделать. А архитектор, в свою очередь, описывает реализацию функций в виде требований и задач на техническом языке. Он объясняет, как выполнить функциональные требования и при этом не забыть про нефункциональные: обеспечить надежность, доступность, производительность системы.
И аналитик, и архитектор могут ставить задачи самым разным командам: разработчикам, и девопсам, тестировщикам, техническим писателям.
Нюансы
Приведу простой абстрактный пример, который иллюстрирует разницу между аналитикой и архитектурой.
Аналитик пишет требование: «Обеспечить в форме на сайте возможность ввести фамилию, состоящую из русских букв».
Архитектор прорабатывает и ставит задачи:
DevOPS: настроить сетевые доступы, необходимые для использования базы данных. Без сетевых доступов код не будет работать, потому что не сможет подключиться к базе данных.
Разработка:
a. Создать схему в базе данных и таблицу для ввода фамилий с колонкой «фамилия». Не должно быть логики и триггеров в базе данных.
b. Написать метод проверки того, что фамилия состоит только из русских букв. В случае ввода любых других символов отображать ошибку — «Что-то пошло не так».
c. Реализовать настройку, отключающую функциональность из п. b. Переключатель обычно делаем на случай, если передумали это использовать или случилась авария после запуска функции. В обоих случаях не требуется дополнительная разработка и правка кода, чтобы удалить функцию и быстро откатиться к стабильной версии.Тестирование:
a. Протестировать возможность ввода любых нерусских символов.
b. Протестировать при вводе фамилии возможность ввода спецсимволов.Технический писатель:
a. Подготовить/доработать руководство пользователя по вводу фамилий.
Перед тем как поставить все эти задачи, архитектор (при необходимости) выбирает базу данных — ту, что быстрее читает данные, или ту, в которую быстрее эти данные можно записать — и технологию для реализации логики и форм работы с фамилией. Форма проверяет, какие символы вводятся в поле. Если символы неправильные (не та раскладка, цифры, спецсимволы), форма сообщает об ошибке.
Итог
В разработке любых систем одинаково важны описания от аналитика и архитектора. Аналитик доступно формулирует требования и образ результата, то есть аналитика понимает заказчик. Работа архитектора поможет сформировать понятные командам задачи и получить результат.
Что со всем этим делать
Подводя итог, хочу дать несколько советов руководителям и архитекторам из своего опыта. Надеюсь, они помогут ввести нового сотрудника в команду быстро и безболезненно для всех.
Руководитель должен заранее подготовить коллег. Рассказать, какие задачи будут возложены на архитектора, чем это будет помогать, как это улучшит продукт. Объяснить, что новый человек будет заниматься теми вещами, которые обычно другим неинтересны: расчеты производительности, работа с требованиями информационной безопасности, документированием архитектуры системы и прочими «скучными» задачами. Это помогает уменьшить сопротивление.
Проводить ретровстречи, где вся команда будет обсуждать рабочие проблемы и решения. В одной из моих команд я прямо говорила, что мы хотим развивать продукт, но задачи от архитектора не выполняем. И в ответ слышала, что кому-то решение не понравилось или показалось странным, сложным с точки зрения кода. И они были правы в таких ситуациях. Мы обсуждали, искали компромисс. Буквально полчаса диалога — и задача уходит в работу без лишнего негатива.
Архитектору могу посоветовать честно и открыто общаться с коллегами. Возможно, первое время понадобится объяснять все решения. Обсуждать их, советоваться. И помогать понять разработчикам, что ты им не враг, который хочет усложнить жизнь.
И руководитель, и архитектор должны донести до коллег, что архитектор не заменит других членов команды, а только дополнит. Его работа помогает сделать общий продукт лучше, безопаснее и удобнее для заказчика. А значит, каждый член команды может заниматься своим любимым делом, оставив остальное (очень важное для компании и заказчика) архитектору.
Делитесь в комментариях своими историями и задавайте вопросы!