Доклад на online-конференции High Performance Systems Conference 2023

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

Краткое содержание. Мой доклад - обобщение 25-летнего опыта Enterprise-разработки. Он говорит о том, что потребности в срочных изменениях в ИТ-ландшафте появились не в 2022 и даже не в 2020, они были всегда. И часто их решением является временный модуль, который решает проблему. Его часто делают, срезая углы и на ручной интеграции, но решение задач бизнеса он обеспечивает. Дальше этот модуль дальше живут своей жизнью, и тут возможны два сценария: либо надо доработать функционал, интеграцию и эргономику, чтобды в системе появился еще один небольшой модуль, либо в .тот модуль постепенно переводят функционал какой-либо из legacy систем, и тогда он становится полноценной системой. Договариваться о сценарии стоит сразу: в острой ситуации бизнес восприимчевее к изменениям.

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

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

Согласиться, что сложный мозаичный ИТ-ландшафт разномасштабных решений — норма. Сейчас так и есть, но я помню время, когда целевой картиной представлялось комплексное решение от одного вендора, быть можзет с дополнительными модулями.
Выделение в системах двух уровней: базы основных исполнительных систем, поверх которого распологаются специализированные рекомендательные и управляющие системы.
Постепенное развитие временных и промежуточных решений в полноценные, наращивая функционал: сначала база, реализующая основные сценарии и позволяющая особые случаи обработать вручную, а затем автоматизируем их по необходимости.
В системах должна быть устойчивая интеграция для создания и изменения документов и справочников, тоже двух уровней: через ручную загрузку-выгрузку и через API. Ручные загрузки и выгрузки часто могут служить основой для временной интеграции, позволяя преобразовывать данные на Excel.
Очень помогает сквозной мониторинг уровня бизнес-процессов для обеспечения целостности. Современные средства позволяют его сделать в мозаичном лагндшафте и подключать новые компоненты.
Желательна база для быстрой разработки: документооборот, учёт, интерфейсы naked objects. Это могут быть low-code решения или решения на базе какого-то фреймворка.

И дальше в докладе были кейсы, которые иллюстрировали такой подход. Многие из них - достаточно старые, и в перспективе нескольких лет можно оценивать, что созданные решения не были времянками, на их основе действительно выросли полноценные системы.