Когда я представляюсь как архитектор программного обеспечения, многие собеседники вежливо кивают, а в глазах у них читается: «дорогой технарь, который рисует квадратики». Это понятная реакция. Работу программиста видно: он написал код, появилась кнопка. Работу дизайнера видно: появился красивый экран. А работа архитектора выглядит как разговоры, схемы и странные вопросы вроде «а что будет, если клиентов станет в десять раз больше».
При этом я убеждён, что хороший архитектор один из самых прибыльных людей в технической команде. Просто его вклад в прибыль заметен не в отчёте за неделю, а в отчёте за годы. И, что ещё хуже для его репутации, лучшая работа архитектора состоит в проблемах, которые так и не случились.
Город, который строили без плана
Возьмите два города. Первый рос сам по себе: где удобно, там и строили, дороги прокладывали по тропинкам, канализацию добавляли, когда становилось совсем плохо. Второй с самого начала строили по генеральному плану: магистрали, кварталы, инженерные сети с запасом на рост.
Через двадцать лет в первом городе пробки, аварии труб, бесконечные ремонты и огромные деньги на то, чтобы проложить новую дорогу через уже застроенные кварталы. Во втором городе тоже бывают проблемы, но они решаются на порядок дешевле, потому что для них предусмотрено место.
Программная система компании это и есть её цифровой город. По нему ездят заказы, деньги, данные о клиентах. Если город строили без архитектора, каждое новое изменение стоит всё дороже, а каждый сбой задевает соседние районы. Деньги утекают через трещины в дорогах, и никто не может показать, где именно.
Где архитектура превращается в деньги
Скорость разработки новых функций. В хорошо спроектированной системе новую функцию можно добавить, не трогая половину существующего кода. Это называется модульностью, и её экономический смысл прост: команда делает больше за то же время. Я видел системы, где добавление нового способа оплаты занимало два дня, и системы, где та же задача занимала два месяца, потому что логика оплаты была размазана по сорока файлам. Разница в стоимости разработки здесь не в процентах, а в разах.
Стоимость инфраструктуры. Облачные серверы оплачиваются каждый месяц, и счета имеют свойство тихо расти. Плохо спроектированная система тратит ресурсы впустую: лишние запросы к базе, отсутствие кэширования, тяжёлые операции, которые запускаются там, где можно обойтись лёгкими. Архитектор, который один раз разобрался в этом, может снизить ежемесячный счёт в несколько раз, и эта экономия повторяется каждый месяц.
Предотвращение простоев. Час, когда интернет-магазин не работает в разгар сезона, стоит потерянных продаж, рекламного бюджета, который продолжал тратиться впустую, и репутации. Архитектор думает о резервировании, мониторинге, восстановлении после сбоев заранее, а не в момент, когда всё уже упало.
Снижение операционных рисков. Утечка данных клиентов, потеря базы без резервной копии, зависимость от одного сервиса, который внезапно закрылся. Каждый из этих рисков в лучшем случае стоит больших денег, в худшем стоит компании. Архитектура это в том числе система страховок.
Свобода найма. Система, построенная на понятных, распространённых технологиях и с читаемой структурой, позволяет быстро подключать новых программистов. Система, построенная на экзотике или на личных изобретениях одного гения, делает компанию заложником этого гения.
Чего архитектор делать не должен
Будем честны: архитекторы тоже умеют уничтожать деньги. Самый частый способ это переусложнение. Микросервисы для системы, которой пользуются двадцать человек. Три уровня абстракции там, где хватило бы одной функции. Подготовка к нагрузке в миллион пользователей у продукта, который ещё не нашёл первую сотню.
Хороший архитектор думает не о том, какая архитектура самая красивая, а о том, какая самая выгодная для конкретного бизнеса на конкретном этапе. Иногда это означает сознательно выбрать простое решение и записать в план, когда его придётся переделать. Это не лень, это экономика.
И ещё одна ловушка: архитектор, который не разговаривает с бизнесом. Он проектирует идеальную систему для задач, которых нет, и не замечает задачи, которые реально приносят деньги. Мой принцип: прежде чем рисовать схему, я должен понять, как компания зарабатывает, где теряет время и что мешает ей расти. Без этого любая архитектура будет красивым городом в пустыне.
Как измерить вклад архитектора
Если Вы руководитель и хотите понять, окупается ли архитектура, смотрите на несколько показателей во времени:
- сколько времени занимает выпуск типовой новой функции и растёт ли это время;
- сколько стоит инфраструктура в расчёте на одного клиента или одну транзакцию;
- сколько часов в квартал система была недоступна;
- сколько времени новый разработчик тратит, чтобы начать приносить пользу.
В системе без архитектуры все эти показатели со временем ухудшаются. Каждая новая функция даётся тяжелее предыдущей, счета растут, сбоев больше. В системе с хорошей архитектурой они остаются стабильными или улучшаются. Разница между двумя кривыми и есть вклад архитектора в прибыль.
Что делаем мы
В Ingello Systems архитектура для нас начинается не с технологий, а с модели бизнеса: какие сущности есть в компании, какие процессы приносят деньги, где узкие места. Потом мы описываем систему формально и с помощью Fractal генерируем основу кода, базы и интерфейсов по единым правилам. Это убирает целый класс архитектурных ошибок, которые возникают, когда каждый программист строит свою часть города по своим представлениям.
Если Вы сомневаетесь, нужен ли Вашей компании архитектор, задайте себе вопрос: становится ли каждое новое изменение в Вашей системе дороже предыдущего? Если да, деньги уже утекают. Вопрос только в том, сколько ещё Вы готовы за это платить.
