АНАЛИЗ СОВРЕМЕННЫХ ПОДХОДОВ К ПРОЕКТИРОВАНИЮ АРХИТЕКТУРЫ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

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

Бахметьев Иван Вадимович,

Магистрант факультета информационных технологий
Московского университета им. С.Ю. Витте;
SPIN-код: 4441-4745, AuthorID: 1253833

АНАЛИЗ СОВРЕМЕННЫХ ПОДХОДОВ К ПРОЕКТИРОВАНИЮ АРХИТЕКТУРЫ
КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

Корпоративная информационная система (далее – КИС) обеспечивает связь между повседневной работой подразделений и управлением компанией. Через неё проходят закупки, расчёты с поставщиками, складские операции, производственные задания и взаимодействие с клиентами. Поэтому ошибка в её архитектуре может проявиться далеко за пределами ИТ-подразделения: заказ принят, но склад не получил сведения о резерве; продукция выпущена, но данные о затратах ещё не попали в учётную систему. При этом каждое приложение по отдельности может работать исправно.

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

Данная тенденция отмечается в статье А. В. Рябинина: «Изменение внешних и внутренних условий развития российской экономики также ведет к пониманию необходимости перехода на отечественные ИТ-решения» [9, с. 8]. Это положение подтверждает, что при проектировании КИС необходимо оценивать не только функциональность программного продукта, но и возможность его долгосрочного сопровождения, интеграции и замены.

Цель данной статьи – определить возможности и ограничения современных подходов к проектированию архитектуры корпоративных систем и сформулировать рекомендации по их применению в российских компаниях. Для достижения цели сопоставляются способы организации приложений и интеграции, рассматриваются опубликованные корпоративные примеры, после чего предлагается последовательность принятия архитектурных решений.

В работе используются методы сравнительного и системного анализа; сопоставляются архитектурные подходы и способы интеграции компонентов, а практические особенности их применения рассматриваются на опубликованных примерах российских компаний.

Сравнение проводится по четырём критериям: возможность независимого изменения компонентов, согласованность данных, сложность эксплуатации и управляемость перехода. Корпоративные примеры отбирались при наличии описания исходной задачи, применённого решения либо порядка его внедрения. Авторский результат работы состоит в формировании последовательности проектирования КИС, в которой определение границ бизнес-функций и ответственности за данные предшествует выбору способа физического развёртывания компонентов. Практическая значимость предложенной последовательности заключается в возможности использовать её при модернизации и поэтапной замене корпоративных систем.

В исследовании А. Б. Анисифорова корпоративная логистика рассматривается через взаимосвязь материальных, финансовых и информационных потоков. Автор отмечает, что «информационные процессы логистики серьезно интегрированы в информационную среду предприятия» [1, с. 54]. Для проектирования это означает необходимость учитывать весь путь операции. Оптимизация закупочного приложения не решит проблему снабжения, если данные о потребности производства остаются несогласованными со складскими остатками. В исследовании М. Г. Трейман и А. М. Михелашвили также рассматриваются корпоративные системы вместе с управлением производственными комплексами и организацией бизнес-процессов [2].

При анализе необходимо разграничивать корпоративную архитектуру, архитектуру приложений и инфраструктурную архитектуру. Корпоративная архитектура определяет взаимосвязь бизнес-процессов, данных и информационных систем предприятия; архитектура приложения подразумевает внутреннюю организацию его компонентов; инфраструктурная архитектура уже определяет способы размещения, масштабирования и эксплуатации решений. Определим теперь подходы к проектированию КИС.

Монолитная архитектура предполагает, что основные функции приложения поставляются и развёртываются совместно. Её достоинство состоит в сравнительно простой организации выполнения операций и сопровождения единого приложения. Однако по мере роста системы изменение одной функции может потребовать проверки множества зависимостей и согласования общего выпуска. Для небольшой команды такое решение нередко удобно, а для нескольких самостоятельных команд общий цикл обновления способен стать ограничением.

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

Микросервисная архитектура обеспечивает возможность независимого изменения и развёртывания компонентов, однако усложняет эксплуатацию и обмен данными [3]. Например, если один сервис зарезервировал товар, а подтверждение заказа не поступило, необходимо предусмотреть механизм отмены резерва и восстановления согласованного состояния системы. Повторная обработка запроса при этом не должна приводить к созданию дублирующих операций.

Для интеграции компонентов могут применяться сервисно-ориентированный и событийный подходы. Синхронные взаимодействия целесообразны при необходимости немедленного получения результата операции, тогда как событийный обмен позволяет снизить связанность компонентов при допустимости задержки обработки. Облачная инфраструктура при этом не устраняет необходимость определения границ компонентов и ответственности за данные.

Основные особенности рассмотренных архитектурных подходов представлены в таблице 1.

Сопоставление показывает, что повышение независимости компонентов сопровождается увеличением сложности эксплуатации системы. Поэтому выбор микросервисной архитектуры целесообразен не вследствие размера приложения как такового, а при наличии требований к независимому изменению, развёртыванию или масштабированию отдельных функциональных областей. Модульный монолит следует рассматривать как самостоятельный архитектурный вариант, а не только как переходную ступень к микросервисам. Он позволяет определить границы предметных областей без переноса взаимодействия между ними в распределённую среду. Следовательно, при проектировании КИС первоначально целесообразно определить границы ответственности компонентов и только затем выбирать способ их физического развёртывания.

В качестве практического примера можно рассмотреть опыт X5 Tech, иллюстрирующий подход к проектированию, при котором новое решение рассматривается как часть общей архитектуры компании. В опубликованном описании архитектурного процесса предусмотрены предварительное обсуждение решений и проверка их соответствия при реализации проекта [4]. Например, при добавлении системы управления складом необходимо определить, откуда она получает сведения о товарах, каким приложениям передаёт остатки и какие функции уже выполняются существующими системами. Эти вопросы определяют границы компонентов и порядок их взаимодействия. Таким образом, значение данного подхода состоит в согласовании отдельных проектов между собой: локально удобное решение должно поддерживать работу всей корпоративной системы.

Архитектурное согласование в X5 Tech включает несколько уровней. Архитектурное ревью проводится два раза в неделю по два часа и собирает от 30 до 45 архитекторов разных направлений. Архитектурный совет также проводится два раза в неделю, а итоговый архитектурный комитет – один раз в неделю. Решение на комитете принимается единогласно: возражение одного участника приводит к возвращению проекта на доработку [4]. Эти показатели демонстрируют, что в крупной компании архитектура представляет собой не только описание программных компонентов, но и установленный порядок коллективной проверки решений.

В то же время практические последствия перехода к большому числу сервисов демонстрирует опыт создания внутренней платформы Ozon. В публикации М. Кабищева от декабря 2022 г. указывалось более 3500 сервисов. Платформа определялась как «внутренние стандарты, сервисы, процессы, инфраструктура для разработки» [5]. В материале рассмотрены общие инструменты создания приложений, сборки и развёртывания, а также стандартизация описаний интерфейсов. Следовательно, речь шла не только о программных библиотеках, но и об организации повторяемого процесса разработки.

Масштаб изменений можно оценить количественно. В 2018 г. в компании работало менее 100 инженеров и использовалось несколько крупных монолитных систем. В публикации 2022 г. уже указывались около 4000 разработчиков, более 3500 сервисов и порядка 3 млн запросов в секунду [5]. При таком количестве компонентов ручное согласование интерфейсов и самостоятельная настройка инфраструктуры каждой командой становятся практически неуправляемыми. Поэтому внутренние стандарты, автоматизированная сборка, единая телеметрия и каталог интерфейсов выступают необходимыми элементами микросервисной архитектуры, а не дополнительными удобствами.

Также следует рассмотреть опыт сотрудничества Росатома и «1С», который показывает актуальность согласования отраслевых процессов при замене корпоративных решений [6]. Наличие требуемой функциональности отдельных компонентов не гарантирует целостности сквозных процессов, поэтому миграция должна учитывать взаимосвязь закупок, производства, учёта и других подсистем.

Однако выявить единый доминирующий подход крайне трудно. Например, международный опрос CNCF и SlashData 2025 г. охватил более 12 тыс. респондентов из 127 стран. Среди опрошенных разработчиков серверных систем 46 % использовали микросервисы [7]. Таким образом, даже в группе специалистов по серверной разработке микросервисы не являются универсальным решением, а применяются вместе с другими архитектурными и интеграционными механизмами.

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

Если предполагается переход из одного подхода к другому, то следует выполнять его поэтапно, проверяя перенос данных и восстановление работы. При замене учётного решения заранее устанавливаются правила сверки остатков и обработки документов, созданных во время переключения. Результат необходимо оценивать по времени выполнения операций, ошибкам обмена, срокам восстановления и расходам, включая обучение и параллельное сопровождение систем.

Проведённый анализ позволяет сформулировать следующий вывод: степень физической распределённости КИС должна определяться после логического разделения бизнес-функций и данных и рассматриваться как изменяемая характеристика системы. Отдельный модуль целесообразно преобразовывать в самостоятельный сервис только при одновременном наличии независимого цикла изменений, необходимости независимого масштабирования и команды, способной обеспечить его эксплуатацию.

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

Другой тенденцией становится включение искусственного интеллекта в существующие бизнес-процессы и информационные контуры предприятия. При этом архитектурной задачей становится не только выбор модели искусственного интеллекта, но и организация контролируемого доступа к корпоративным данным, проверка результатов и регистрация действий. Необходимость управления процессами и рисками, связанными с применением искусственного интеллекта, отражена также в ГОСТ Р ИСО/МЭК 42001–2024 [8]. В архитектуре КИС целесообразно предусматривать возможность замены используемой модели без перестройки всей системы. Таким образом, перспективная КИС представляет собой не фиксированный набор технологий, а архитектуру с устойчивыми границами бизнес-функций и данных, внутри которой отдельные технологические компоненты могут изменяться по мере появления новых требований. 

.

Литература

1. Анисифоров А. Б. Модель информационно-сервисной поддержки корпоративных логистических процессов в архитектуре предприятия // Научный журнал НИУ ИТМО. Серия «Экономика и экологический менеджмент». – 2023. – № 1. – С. 54–63. – DOI: 10.17586/2310-1172-2023-16-1-54-63. – URL: https://economics.ihbt.ifmo.ru/file/article/21835.pdf (дата обращения: 24.09.2026).
2. Трейман М. Г., Михелашвили А. М. Корпоративные информационные системы как основа управления для промышленных предприятий // Управленческий учет. – 2024. – № 1. – С. 155–159. – DOI: 10.25806/uu12024155-159. – URL: https://www.uprav-uchet.ru/index.php/journal/article/view/4143 (дата обращения: 24.09.2026).
3. Клоков В. Н., Вечерская С. Е. Задачи и эволюция микросервисной архитектуры // Вестник Российского нового университета. Серия «Сложные системы: модели, анализ и управление». – 2023. – № 1. – С. 37–42. – DOI: 10.18137/RNU.V9187.23.01.P.37 – URL: https://search.rads-doi.org/showfile/ru/43030 (дата обращения 24.09.2026).
4. Фролочкина В. Короткий или длинный путь: зачем проекту корпоративный архитектор? // Хабр. Блог компании X5 Tech. – 11.04.2024. – URL: https://habr.com/ru/companies/X5Tech/articles/807067/ (дата обращения: 24.09.2026).
5. Кабищев М. Одна платформа, чтобы править всеми // Хабр. Блог компании Ozon Tech. – 29.12.2022. – URL: https://habr.com/ru/companies/ozontech/articles/708274/ (дата обращения: 24.09.2026).
6. Росатом и 1С заключили меморандум о сотрудничестве в области информационных технологий // Атом Медиа. – 06.06.2024. – URL: https://atommedia.online/press-releases/rosatom-i-1s-zakljuchili-memorandum-o-sot/ (дата обращения: 24.09.2026).
7. State of Cloud Native Development Q3 2025 // Cloud Native Computing Foundation, SlashData. – 2025. – URL: https://www.cncf.io/reports/state-of-cloud-native-development/ (дата обращения: 26.09.2026).
8. ГОСТ Р ИСО/МЭК 42001-2024. Искусственный интеллект. Система менеджмента. – Введ. 01.01.2025. – М.: Российский институт стандартизации, 2024. – URL: https://protect.gost.ru/gost/details/3cb023c3-e628-45ad-b233-65e3d175eb10.
9. Рябинин А. В., Бахметьев В. А. Автоматизация процессов управления на основе российских разработок в сфере информационных технологий // Промышленная политика в Российской Федерации. – 2025. – № 1–3. – С. 7–11. – URL: https://prompolit-press.ru/ru/blogs/avtomatizatsiya-protsessov-upravleniya-na-osnove-rossijskikh-razrabotok-v-sfere-informatsionnykh-tekhnologij (дата обращения: 29.09.2026).

/

Ключевые слова: корпоративная информационная система, архитектура информационных систем, корпоративная архитектура, монолитная архитектура, модульный монолит, микросервисная архитектура, интеграция информационных систем, событийная архитектура, искусственный интеллект.