Архитектор будущего — человек и ИИ будут вместе строить цифровой мир

Архитектор будущего — человек и ИИ вместе строят цифровой мир

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

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

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

Это не прогноз. Это разговор с тем, кто уже строит то самое будущее.

— Антон, вы начинали как разработчик, но со временем стали архитектором. В чём разница между этими ролями?

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

— Вы внедряли Domain-Driven Design (DDD)*. Почему именно DDD?

— Мы работали с огромным легаси-монолитом**. Любое изменение было болезненным — один модуль ломал другой, тестирование превращалось в кошмар, новые сотрудники учились по году. Я предложил DDD, и для многих это выглядело как усложнение: новые слои, новые классы, другая логика. Но через несколько месяцев стало ясно: изменения в одном модуле перестали влиять на соседние. Время вывода новых функций сократилось в разы. Разработчики начали понимать систему быстрее.

В новом проекте мы строили архитектуру с нуля вокруг DDD. Модули были независимыми с самого начала. Команды работали параллельно, не мешая друг другу. Это позволило запустить платформу за полтора года — невероятно быстро для такого масштаба.

* Предметно—ориентированное проектирование (Domain-Driven Design, DDD) предлагает подход к созданию сложных систем из простых и ясных компонентов. DDD — это не просто архитектурный стиль, а методология проектирования, где основу составляют сущности предметной области. В такой архитектуре базовыми элементами системы становятся небольшие компоненты, отражающие конкретные бизнес-понятия.

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

— Вы упомянули, что внедрение Domain-Driven Design изначально воспринимали как усложнение. Как вам удалось убедить команду и руководство?

— Внедрение DDD не было прихотью. Мы столкнулись с невозможностью масштабировать большой легаси-монолит, где любое изменение было болью. Тогда я организовал серию встреч и брейнштормов с участием CTO и старших разработчиков, где мы совместно сформировали требования к будущей архитектуре. После этого я изучал существующие в индустрии подходы и обратил внимание на DDD. Хотя на тот момент информации было немного и в основном она носила теоретический характер, предлагаемый DDD подход полностью соответствовал нашим требованиям.

Моё убеждение строилось не на абстрактных доводах, а на конкретных результатах. Я предложил внедрить подход через прототип, который наглядно показал, что изменения в одном модуле перестали «ломать» соседние. Время вывода новых функций сократилось в разы, а новые сотрудники стали входить в проект не за год, а за две недели. После этого мы почти сразу начали разрабатывать новые части системы на DDD.

— Другой ваш крупный проект — российская альтернатива SAP Ariba, которую создали всего за полтора года. Что позволило так быстро добиться результата?

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

Архитектура нового продукта изначально была построена на DDD, что позволило явно разделить систему на независимые модули. Разные команды могли работать над компонентами изолированно, но по общим принципам. Ключевое преимущество — гибкость и масштабируемость, в отличие от громоздких монолитов. Мы могли быстро реагировать на запросы рынка, для которого SAP уже перестал существовать.

— Можете привести пример, когда «плохая» архитектура почти привела к провалу?

— Именно с такими проблемами мы столкнулись на электронной торговой площадке до перехода на DDD. Мы не были на грани провала, но испытывали серьёзные ограничения. Бизнес-логика была переплетена с интерфейсом и инфраструктурным кодом. Любое исправление порождало новые баги, automated testing было почти невозможно реализовать. Это тормозило релизы, снижало прибыль и демотивировало команду. Мало кто хотел работать с системой, где всё постоянно ломалось.

— Сейчас всё больше говорят об ИИ в разработке. Не делает ли он архитектора излишним?

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

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

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

— Сегодня вы работаете над продуктом для ветеринарных клиник. Как в вашей работе используется ИИ?

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

— Если бы вы сейчас начинали готовить молодого архитектора с нуля, на что бы сделали упор?

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

Я бы выделил несколько приоритетов:

Понимание бизнеса. Умение переводить бизнес-задачи в технические решения. Системное мышление. Видеть архитектуру в целом, а не только отдельные модули. Навыки коммуникации. Способность договариваться с разработчиками, бизнесом и руководством. Практический опыт. Писать код, чтобы видеть последствия своих решений. Гибкость. Не зацикливаться на технологиях, а подбирать инструменты под задачу.

— Какую главную ошибку допускают начинающие архитекторы?

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

— И последний вопрос. Как вы видите архитектуру через 10 лет? Будут ли системы полностью автономными?

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

P. S.
Антон Мусатов — не просто технический эксперт, а мыслитель, который видит за кодом — систему, за системой — бизнес, а за бизнесом — будущее. Его путь от разработчика до архитектора — это переход от исполнения к ответственности. В эпоху, когда ИИ всё чаще заменяет человека в рутине, такие специалисты становятся всё более востребованными — как те, кто умеет думать шире, видеть дальше и принимать решения, от которых зависит не только продукт, но и судьба компании.

Источник: argumenti.ru