Три типа архитекторов и лестница масштаба
Александр начинает с собственной классификации: софтовые архитекторы работают внутри инженерных команд и помогают развивать их сервисы; solution-архитекторы собирают сквозное решение под новый бизнес-процесс из многих систем и команд; enterprise-архитекторы оперируют высокоуровневыми фреймворками вроде TOGAF или Захмана. Третий тип он считает скорее зоной ответственности CTO: выделенный enterprise-архитектор отрывается от деталей реализации и остаётся со стрелочками, кружочками и презентациями, далёкими от реальности, — «полумифический образ». Владимир добавляет, что решение многогранно — интерфейсы, мобильные приложения, веб, ближний и дальний бэкенд, хранение данных, машинное обучение, аналитика, пайплайны сборки, — и под домены нужны свои специалисты: архитекторы мобильных приложений, дата-архитекторы, знающие гарантии разных семейств баз и тонкости Postgres и Kafka, и системные архитекторы, отвечающие за поставку и рантайм; такой термин, по его словам, встречается в Microsoft и сервисных компаниях вроде Accenture.
Ведущий предполагает, что архитектура спускается сверху вниз, от enterprise к деталям, но Владимир ведёт лестницу снизу: разработчик делает фичи, потом хочет собрать целое приложение со слоями и временем сборки, потом обнаруживает, что рядом с его квадратиком в системе ещё двадцать пять таких же, дальше идут solution, предприятие и CTO. Верхняя ступень — масштаб планеты: в разговоре про облака звучит, что у гугловского CDN 128 крайних точек, и объясняется зачем — из-за скорости света видео из Москвы в Бразилию стартует несколько секунд, а ближайшая точка сокращает задержку примерно до полусекунды; ведущий сравнивает это со складами за МКАДом, гости — с IT-складами. Историю профессии Александр выводит из строительства: труд одного из архитекторов о паттернах в градостроительстве, кирпич примерно на тысячу страниц, стал прообразом книг о шаблонах в разработке, а закон Мелвина Конвея про три отдела и трёхпроходный компилятор сформулирован больше пятидесяти лет назад.
Кредит маркетплейсам и платформа привлечения
Владимир показывает роль на своём продукте: продавец на Wildberries продал партию, хочет закупить больше и приходит за двумя миллионами, чтобы заработать три. До сентября прошлого года обороты проверяли по банковским выпискам — ручные действия и дни ожидания, хотя отдел оптимизирует time to yes, время до одобрения кредита. Для торгующих на маркетплейсах сделали отдельный продукт: договорились с Яндекс.Маркетом, и теперь мерчант нажимает кнопку прямо там, оставляет телефон, а номер мерчанта передаётся прозрачно, банк сам запрашивает обороты, загружает и преобразует их, складывает в хранилище и дёргает скоринг — решение занимает часы вместо дней. Работу архитектора он описывает буквально: собрал требования — сколько клиентов, как быстро решаем, где и в каком виде храним данные, синхронно или асинхронно ходим в кредитный процесс, — вместе с коллегами выбрал технологии, нарисовал принципиальную схему, записал допущения, прикинул сроки и договорился про контракт. Эксперимент стал одним из кирпичиков к целому направлению работы с e-commerce.
У Александра история платформенная. Больше пяти лет назад его позвали в онлайн-привлечение: клиенты приходили через веб-формы, старое решение к концу 2016 года уже сворачивали, а при переезде на новую фронтовую платформу на React выяснилось, что не работают аналитика и трекинг событий, нет server-side rendering, а значит, и SEO. Он подчёркивает, что делал не он: от него шло направление, обычно оформленное как RFC — вот здесь жмёт, вот вариант решения, давайте обсудим и закоммитимся. Насмотренность, по его словам, приходит, когда читаешь и пробуешь применить: лет семнадцать назад он попал на legacy-проект после ухода старой команды, чувствовал боль и начал с «Совершенного кода» Стива Макконнелла. Владимир сравнивает это с вождением: сначала не понимаешь, за что хвататься, потом видишь, что здесь хватит Postgres, а здесь надо подумать. Оба считают, что практики мало: курсы выстраивают знание деревом, а школу архитектуры им пришлось делать самим — у вендоров не нашлось нужной полноты.
Командный игрок и цена роли
Ключевая книга выпуска — «Идеальный командный игрок»: Александр говорит, что впитал эту философию, и на проектных интервью проверяет три качества — hungry, humble, smart. Человеку нужно чего-то достигать, он не смотрит свысока на джунов и коллег других специализаций и социально умён, то есть умеет понять чужую точку зрения. Для архитектора это критично: стратегические задачи вытесняют работу руками, потрогать новую базу или сервис-меш уже некогда, остаётся советоваться с теми, у кого этот опыт есть, — а диалог получается только на равных. Владимир добавляет «Leadership without authority» — лидерство без формального авторитета: доверие строится, когда публично признаёшь слабости и спрашиваешь, как считают коллеги. Александр уточняет: формальных полномочий продавливать решения у архитектора обычно нет, а если есть, лучше ими не пользоваться. Критику Владимир предпочитает давать вопросами — не «это не будет работать», а «как система поведёт себя вот в таких условиях».
Отсюда вывод Александра: решения нужно принимать на том уровне, где люди способны их принять, а сам процесс делать прозрачным и децентрализованным — документ с проблемой, альтернативами и выбором отдаётся команде на комментарии. Так архитектор становится играющим тренером, а его импакт растёт вместе с командой; успех архитектора — это успех команды, подытоживает Владимир. Он вспоминает «Бесконечную игру» Саймона Синека: цель не выиграть квартальный отчёт, а сохранить возможность продолжать играть. Ветки роста он раскладывает так: масштаб решений вплоть до стратегии на три-пять лет, менеджмент людей до директора и вице-президента по инженерии, delivery management с бюджетами и P&L в сервисных компаниях и продуктовое управление. Минусы тоже названы честно: профдеформация «it depends» — в базовом курсе Александра есть треугольник безопасности, производительности и стоимости, где всё тянет в разные стороны, — отложенный на годы результат работы и соблазн обвинить предшественников вместо разбора контекста их решений. В финале ведущий спрашивает про детские мечты: космонавт и учёный у Александра, астрономия у Владимира.
Что стоит унести с собой
- 01Архитектор — это роль, а не должность: она есть с первого дня даже в стартапе, но выделенный человек появляется редко, и без обеих половинок, технической и менеджерской, роль не работает.
- 02Три качества идеального командного игрока — hungry, humble, smart — для архитектора не про мораль, а про доступ к чужому опыту: сам он руками все технологии потрогать уже не успевает.
- 03Процесс архитектурных решений стоит делать прозрачным и децентрализованным: документ с проблемой и альтернативами отдаётся команде на комментарии, а критику полезнее давать вопросами.
- 04Серебряных пуль нет: безопасность, производительность и стоимость тянут в разные стороны, а нефункциональные требования легче продать бизнесу как архитектурные характеристики решения.