В современной IT-индустрии сложилась молчаливая норма: корпоративные системы живут три-пять лет, после чего их проще переписать с нуля, чем продолжать развивать. Технический долг накапливается, интеграции усложняются, и однажды стоимость изменений становится неподъёмной. Команды берутся за полный рефакторинг, бизнес несёт убытки, а пользователи месяцами живут в переходном хаосе.
Но что, если система может работать десять, пятнадцать, двадцать лет — и при этом спокойно принимать новые бизнес-модели, интеграции и технологии без переписывания архитектуры?
Акжолбек Оморов — инженер-программист и системный архитектор, который последовательно строит системы именно по такому принципу. В его портфолио — ERP-платформа для строительных компаний Кыргызстана, которая с 2013–2014 годов работает более чем в пятнадцати компаниях без кардинальной перестройки архитектуры; государственные системы национального масштаба, через которые проходят выборы и бюджетные деньги целой страны; специализированная платформа управления скидками по топливным картам для американской транспортной отрасли. При этом он закрывает полный цикл разработки в одиночку — от исследования задачи до промышленной эксплуатации — и с первого дня строит продукт на уровне надёжности банков и государственных систем.
В интервью он рассказывает, почему архитектор должен работать не ради сегодняшнего релиза, а ради изменений, которые произойдут через десятилетие, и показывает, что долгоживущие системы — это не удача, а результат конкретных архитектурных решений.
— Акжолбек, большинство корпоративных систем в индустрии переписывают каждые несколько лет. Вы же утверждаете, что это не неизбежность, а следствие неправильной архитектуры. Почему переписывание стало нормой?
— Потому что большинство систем проектируются под текущие процессы, а не под будущие изменения бизнеса. Компания растёт, появляются новые интеграции, меняются требования, и через несколько лет архитектура перестаёт вмещать всё это без постоянных «костылей». В какой-то момент команда принимает решение переписать — и цикл повторяется.
Я работаю иначе. Ещё в 2013–2014 годах я начал разрабатывать ERP-систему для строительных компаний Кыргызстана — платформу, которая автоматизирует полный цикл продаж квартир в строящихся жилых комплексах: ведение объектов, резервирование, оформление договоров, рассрочки, графики платежей, финансовый учёт, аналитику и сопровождение клиентов. Сегодня эта система эксплуатируется более чем в пятнадцати строительных компаниях и продолжает развиваться без необходимости кардинального переписывания архитектуры.
— Почему именно этот проект стал показательным?
— Потому что за годы эксплуатации девелоперский рынок Кыргызстана существенно изменился. Компании внедряли новые модели продаж, меняли схемы финансирования, автоматизировали документооборот, подключали новые сервисы и перестраивали внутренние процессы. Система должна была принять все эти изменения. Если бы архитектура была спроектирована только под процессы 2014 года, её пришлось бы переписывать уже через три-четыре года.
Главный показатель качества корпоративной системы — не успешный запуск, а способность развиваться спустя годы после внедрения. Запустить может практически любая команда. Настоящий экзамен начинается через десять лет, когда бизнес меняется, появляются новые требования, а архитектура либо позволяет спокойно развиваться, либо начинает тормозить компанию.
— Вы говорите о прогнозировании изменений. Но ведь никто не может точно предсказать, что будет с бизнесом через десятилетие.
— И не нужно предсказывать конкретные изменения. Нужно проектировать систему так, чтобы она могла принять изменения любого рода. Самый важный вопрос для архитектора — не «что будет делать бизнес через пять лет», а «какого рода изменения могут произойти» и «сможет ли система принять их без капитальной перестройки».
Это вопрос не предвидения, а инженерной дисциплины. Архитектура должна быть рассчитана не только на масштабирование нагрузки, но и на изменение самого бизнеса: смену бизнес-модели, законодательства, интеграций и технологий. Если после всех этих изменений систему не приходится переписывать — значит, архитектура выполнила свою задачу.
— В 2025 году вы разработали платформу для американской транспортной отрасли — управление скидками по топливным картам. Предметная область совершенно другая. Архитектурные принципы изменились?
— Нет, и это ключевой момент. Принципы хорошей архитектуры не меняются в зависимости от предметной области. Предметная область может полностью измениться — от строительного сектора Кыргызстана до рынка грузоперевозок США, — но архитектурный фундамент остаётся тем же.
В этой платформе система автоматически учитывает объём приобретённого топлива, предоставленные перевозчикам скидки, историю заправок, финансовые расчёты и формирует аналитику для транспортных компаний. Одновременно мобильное приложение предоставляет водителям прозрачную информацию о количестве приобретённых галлонов, размере полученных скидок и накопленной статистике. Но под капотом — те же принципы: модульность, слабая связанность компонентов, чёткие границы между подсистемами.
— Что именно вы имеете в виду под «слабой связанностью»?
— Когда одна новая функция требует изменить десять уже работающих подсистем — это и есть чрезмерная связанность. Такая архитектура — самая опасная: каждое обновление становится дороже предыдущего, потому что затрагивает всё больше частей системы.
Модульность и слабая связанность компонентов — это то, что позволяет снизить влияние архитектурного технического долга. Когда создаёшь корпоративную систему, ты строишь не программу, а фундамент. Всё остальное — новые модули, интеграции, мобильные приложения, искусственный интеллект — должно спокойно достраиваться поверх этого фундамента, не разрушая его.
— В вашем портфолио есть государственные системы национального масштаба. Что это за проекты?
— Это системы, через которые проходят выборы и бюджетные деньги целой страны. Когда ты работаешь на таком уровне, цена ошибки измеряется не в рублях или долларах, а в доверии к государственным институтам. Здесь нельзя себе позволить «выкатить и посмотреть, что будет».
На ряд решений в этой области у меня есть патенты. Но важнее другое: эти системы работают годами, принимая изменения в законодательстве, в процедурах, в технологиях — и архитектура выдерживает эти изменения.
— Вы упоминаете, что в одиночку закрываете весь цикл разработки. Это не противоречит идее сложных систем, над которыми обычно работают команды?
— Это не противоречие, а другой подход к организации работы. В классической модели команда делится на роли: аналитик, архитектор, бэкенд, фронтенд, DevOps, тестировщик. Каждое звено отвечает за свой участок, и на стыках между ними теряется контекст.
Когда один человек проходит весь цикл — от исследования задачи до промышленной эксплуатации, — он удерживает всю картину целиком. Он видит, как решение на уровне базы данных повлияет на пользовательский интерфейс через год и как выбор технологии сегодня скажется на стоимости сопровождения через пять лет.
Конечно, это не означает, что большие команды не нужны. Для крупных продуктов требуется несколько инженеров или архитектурная группа. Но ключевой принцип остаётся: в команде должен быть уровень, отвечающий за целостность системы на длинном горизонте.
— Как вы ускоряли разработку в промышленной компании с месяца до десяти дней?
— За счёт перестройки процесса, а не за счёт «больше людей» или «больше часов». Ускорение втрое — это не про то, чтобы работать быстрее. Это про то, чтобы убрать архитектурные и процессные препятствия, которые замедляют движение.
Часто разработка тормозится не из-за слабой команды, а из-за того, что архитектура не позволяет быстро вносить изменения. Каждая новая функция требует согласований с пятью подсистемами, переделки общих модулей, длительных регрессионных тестов. Когда вы устраняете эти архитектурные препятствия, разработка естественным образом ускоряется — без героических усилий.
— Сейчас все говорят об искусственном интеллекте. Как ИИ вписывается в вашу философию долгоживущих систем?
— Новые технологии должны становиться естественным продолжением существующей платформы, а не причиной создания очередной версии продукта. Если архитектура спроектирована правильно, вы можете добавить AI-модуль, аналитическую платформу или интеллектуальную автоматизацию поверх существующей системы — и она это примет.
В моём проекте с топливными картами для США автоматическое распознавание документов на основе искусственного интеллекта — это не отдельный продукт, а модуль внутри платформы. Через пять лет, когда появятся более совершенные AI-модели, их можно будет заменить без переписывания остальной системы.
Архитектор работает не ради сегодняшнего релиза. Его задача — сделать так, чтобы через десять лет команда обсуждала новые возможности системы, а не очередной проект её полного переписывания.
— Как бизнесу понять, что его система спроектирована правильно, а не просто «работает»?
— По тому, как система принимает изменения. Если каждая новая функция требует переделки десятка мест, если обновления становятся дороже и рискованнее с каждым годом, если команда постоянно говорит «это сложно добавить в текущую архитектуру» — значит, фундамент слабый.
Хорошая система переживает не только рост количества пользователей. Она должна пережить смену бизнес-модели, законодательства, интеграций и технологий. Если после этого её не приходится переписывать — значит, архитектура выполнила свою задачу.
Опыт проектов в строительной отрасли Кыргызстана и транспортной индустрии США показывает: долгоживущие информационные системы появляются не благодаря удачному выбору технологий. Их объединяет другое — архитектурные решения, которые изначально принимаются с расчётом на многолетнюю эксплуатацию, постепенное развитие и способность адаптироваться к изменениям бизнеса без потери устойчивости.
— Какой главный принцип вы бы сформулировали для архитекторов и руководителей IT-проектов?
— Архитектор работает не ради сегодняшнего релиза, а ради изменений, которые произойдут через пять, десять, пятнадцать лет. Хорошая архитектура — это не та, которая идеально отвечает на сегодняшние требования. Это та, которая спокойно принимает требования, которые сегодня ещё никто не сформулировал.
Когда компания проектирует систему только под текущие процессы, она закладывает технический долг, который через несколько лет придётся выплачивать полным переписыванием. Когда архитектура строится с расчётом на изменения — система живёт десятилетиями, развиваясь вместе с бизнесом, а не вопреки ему.
— Спасибо, Акжолбек. Получился разговор о том, что настоящая инженерная работа невидима. Она не в красивом интерфейсе, а в том, что интерфейс можно поменять десять раз — и дом не рухнет.
— Да. Именно поэтому я строю фундаменты, а не декорации.
