Импортозамещение, open source и архитектурный суверенитет
Уход западных вендоров поставил компании перед реальным архитектурным выбором. Разбираю, как думать о нём системно, а не реактивно.
2022 год резко ускорил разговор об импортозамещении в IT. Уход или приостановка работы SAP, Oracle, Microsoft и десятков других западных вендоров из российского рынка поставил многие компании в ситуацию, к которой они не были готовы.
Реакция бизнеса разделилась на два полюса. Одни бросились искать прямые замены продукт-за-продукт. Другие встали в режим ожидания, рассчитывая, что ситуация изменится. Ни та, ни другая стратегия не является полноценным ответом.
Я хочу предложить более системный способ думать об этой проблеме.
Три разных вопроса под одним словом
"Импортозамещение" в текущем контексте смешивает как минимум три разных задачи, и их стоит разделять.
Операционная непрерывность - это вопрос "что делаем прямо сейчас, если конкретный продукт стал недоступен". Это краткосрочная задача с ограниченным горизонтом.
Снижение зависимости - это вопрос "как перестроить архитектуру так, чтобы зависимость от одного вендора не создавала критический риск". Это среднесрочная задача.
Архитектурный суверенитет - это вопрос "как выстроить IT-инфраструктуру так, чтобы стратегические решения принимались внутри компании, а не диктовались дорожной картой внешнего поставщика". Это долгосрочная задача.
Ошибка - решать долгосрочную задачу методами краткосрочной. Прямая замена SAP на российский аналог без переосмысления архитектуры - это смена одной зависимости на другую.
Где open source меняет расчёты
Здесь важно понимать реальное положение дел с open source в корпоративных системах.
Значительная часть современной IT-инфраструктуры уже работает на open source компонентах - базы данных (PostgreSQL, MySQL, ClickHouse), операционные системы (Linux), инструменты оркестрации (Kubernetes), языки и фреймворки. Для этих компонентов вопрос "заменить западный продукт" не стоит, потому что они изначально не принадлежат ни одному вендору.
Напряжение возникает в другом классе систем: корпоративные ERP, BI-платформы, специализированные отраслевые решения. Здесь open source-альтернативы либо уступают по функциональности, либо требуют значительных инвестиций в адаптацию и поддержку.
Честный ответ: для ряда корпоративных систем хорошей готовой замены нет. Это не повод для паники - но это требует стратегического выбора, а не поиска ближайшего аналога.
Как думать о переходе
Первый шаг - инвентаризация зависимостей. Для каждой критической системы: какой вендор, каков риск недоступности, каковы альтернативы, какова стоимость перехода?
Второй шаг - классификация по критичности и горизонту. Не всё надо заменять немедленно. Некоторые системы можно поддерживать в текущем состоянии несколько лет. Другие требуют действий в ближайшие месяцы.
Третий шаг - выбор стратегии для каждой категории. Прямая замена, переход на open source с кастомизацией, разработка собственного решения или отказ от функционала - это разные стратегии с разными стоимостями и рисками.
Четвёртый шаг - оценка внутренних компетенций. Open source решение, которое некому поддерживать, - не решение. Вопрос "есть ли у нас команда для этого" должен задаваться до, а не после.
Практический вывод
Архитектурный суверенитет - это не цель "поставить всё российское". Это способность принимать стратегические решения о своей IT-инфраструктуре без принудительной зависимости от решений, которые принимаются за рубежом.
Open source - один из инструментов достижения этой цели. Не единственный и не всегда лучший. Но для многих базовых слоёв инфраструктуры он уже является зрелым выбором с работающей экосистемой.
Начните с честного ответа на вопрос: от каких внешних систем вы зависите критически, и что будет, если доступ к ним прекратится? Это более полезный вопрос, чем поиск замены конкретному продукту.