Первым шагом на этом пути является переосмысление роли EA. В контексте импортозамещения архитектура предприятия становится командным центром, который фокусируется на четырех ключевых доменах: бизнес-архитектура, архитектура приложений, архитектура данных и технологическая архитектура. Цель — обеспечить, чтобы каждое решение по замене было согласовано со стратегическими бизнес-целями (например, обеспечение непрерывности критических процессов), а не диктовалось только технической доступностью аналогов.
Разработка целевой архитектуры (Target Architecture) — ядро процесса. Нельзя замещать что попало и как попало. На основе модели текущего состояния (As-Is) архитекторы должны спроектировать модель целевого состояния (To-Be), которая определяет:
- Целевой технологический стек: Какие отечественные ОС (Astra Linux, RED OS), СУБД (PostgreSQL-based решения, Tarantool), middleware, платформы разработки и инструменты мониторинга будут стандартом.
- Принципы интеграции: Как новые системы будут взаимодействовать друг с другом через открытые API (REST, gRPC, очереди сообщений) и стандарты данных, минимизируя вендорную привязку.
- Архитектурные паттерны: Акцент на микросервисную архитектуру, контейнеризацию (Docker, российские аналоги) и оркестрацию (Kubernetes). Это повышает гибкость и позволяет заменять отдельные сервисы без перестройки всей системы.
- Управление данными: Стратегия миграции и конвертации данных из старых систем в новые форматы, обеспечение их целостности, безопасности и соответствия регуляторным требованиям (152-ФЗ, 187-ФЗ).
- Функциональное соответствие: Не 100% покрытие, а покрытие критических для бизнес-процессов функций.
- Интегрируемость: Способность решения вписаться в целевую архитектуру через открытые протоколы.
- Масштабируемость и производительность: Соответствие будущим нагрузкам.
- Жизненный цикл и экосистема: Наличие сообщества, roadmap разработчика, качество документации.
- Общая стоимость владения (TCO): Включая затраты на миграцию, адаптацию, обучение и поддержку.
- Внедрять пилоты и MVP на некритичных участках.
- Создавать «прослойки» и адаптеры (API-шлюзы, ETL-инструменты) для обеспечения совместной работы старых и новых систем.
- Приоритезировать замену систем, исходя из бизнес-критичности и уровня рисков (сначала инфраструктура и ОС, затем СУБД, затем бизнес-приложения).
- Параллельно развивать компетенции команды.
- Установление архитектурных комитетов для контроля за соблюдением стандартов.
- Создание внутренних low-code платформ и фабрик разработки на основе утвержденного стека для ускорения создания новых бизнес-приложений.
- Постоянный мониторинг технологического ландшафта для оценки новых отечественных решений и их плавной интеграции.
- Фокус на безопасности (security by design) и киберустойчивости архитектуры.
Комментарии (14)