ПО, основанное на подписке, легче интегрировать, чем традиционное корпоративное ПО, но проблема для ИТ-руководителей заключается в управлении процессом подключения SaaS, отмечают опрошенные порталом ComputerWeekly эксперты.

В прошлом ИТ-отделы приступали к реализации масштабных программ интеграции корпоративных приложений, чтобы объединить разрозненные данные бизнес-программ. Однако теперь они уже не могут позволить себе планировать такую долгосрочную стратегию. Эпоха ПО как сервиса (SaaS) и публичных облаков привела к появлению огромного количества приложений, каждое из которых создает свой собственный «бункер» данных, который централизованные ИТ-службы вряд ли смогут поддерживать.

По мнению Эндрю Комеса, главного аналитика компании Gartner, речь идет о противопоставлении контроля и качества — скорости. «Центральная группа интеграции может быть узким местом», — говорит он.

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

Стратегия управления

Deutsche Bank использует Terraform компании HashiCorp для создания «рамок» для разработчиков ПО. Кит Кемсли, руководитель отдела предоставления облачных услуг банка, поясняет: «С самого начала мы хотели создать среду, которая способствовала бы быстрому внедрению инноваций, но при этом поддерживала бы и превосходила наши стандарты безопасности и соответствия нормативным требованиям».

Совместно с компанией банк разработал инструмент Sentinel на базе Terraform. Этот инструмент предлагает фреймворк «политика как код», который команда облачной платформы Deutsche Bank использовала для создания библиотеки инфраструктурных модулей Terraform и стандартизированных политик для команд разработчиков приложений.

Deutsche Bank использует концепцию облачных Landing Zone, в рамках которой создаются среды для разработчиков, приемочного тестирования и производственных команд, а также ограждения, обеспечивающие безопасную доставку нового ПО и обновлений. Такой подход, ориентированный на обеспечение безопасности, помог исключить необходимость в команде платформенных разработчиков.

«Внедрение политики как кода не только усилило наши средства контроля, — добавляет Кемсли, — но и позволило многократно использовать ее в наборе сервисов, которые мы предоставляем в трех различных средах, что означает возможность ее адаптации к конкретным приложениям».

Перегрузка приложений

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

«Я думаю, что дело не столько в соединении SaaS с не-SaaS, сколько в количестве приложений, — говорит он. — Портфели приложений резко увеличились в размерах — на крупных предприятиях часто встречаются сотни приложений».

Как отмечает Мутер, количество возможных связей между приложениями увеличивается экспоненциально с каждым новым приложением, что означает, что управление интеграциями «точка-точка» между всеми приложениями является нерациональным. «Несмотря на разрастание SaaS, унаследованные корпоративные системы не исчезнут в одночасье, поскольку затраты на их замену огромны», — добавляет он.

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

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

«Мы получаем требования от бизнеса и задаемся вопросом, как мы можем соединить различные приложения, чтобы эти изменения произошли. Это работало, когда было всего несколько приложений, с которыми приходилось иметь дело, но сегодня возникает проблема экспоненциального роста соединений», — говорит он.

По мнению Мутера, ошибка ИТ-подразделений заключается в том, что они считают, что ценность создают приложения, в то время как, по его мнению, ИТ-лидеры должны сосредоточиться на интерфейсах прикладного программирования (API). «Именно ваши бизнес-процессы создают ценность, а не приложения, — говорит он. — Если вы используете стратегию API, при которой ваши основные API являются интерфейсами для бизнес-возможностей, а не для приложений, то все становится гораздо более мощным».

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

Он приводит пример использования API, обеспечивающих взаимодействие бизнес-процессов: «Каждый раз, когда вам нужно, скажем, выполнить заказ для нового бизнес-партнера или нового канала, вы просто вызываете свой API для выполнения заказа, а не пытаетесь связать три системы управления заказами и восемь ERP с новым партнером или каналом».

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

Сиим Кибус, руководитель инженерной службы компании Pipedrive, рекомендует ИТ-руководителям обеспечить единообразие API. «В идеале API должны быть ориентированы на единый дизайн, отвечать общим принципам проектирования, документации и процессам, обеспечивающим качественный результат, — говорит он. — Разработчики получают лучшие результаты, когда они специально проектируют с учетом требований безопасности, эффективности и экономии ресурсов».

Еще одна проблемная область, с которой могут столкнуться ИТ-руководители, — это взаимодействие современных облачных приложений с унаследованными приложениями, которые не были рассчитаны на работу с данными реального времени. «Я часто вижу это на примере старых ERP», — отмечает Мутер. По его словам, в этом случае ИТ-руководителям может потребоваться управление мастер-данными или кэширование данных для обработки операций чтения для API бизнес-интерфейсов. Это поможет снизить нагрузку на унаследованное приложение.

«В краткосрочной перспективе, — говорит он, — создание соединений „точка-точка“ проще и может быть приемлемым подходом, если у вас очень мало приложений, или для простых сценариев использования, которые, как вы знаете, не будут расти или повторно использоваться в будущем». Однако на высоком уровне он рекомендует организациям стремиться к оркестровке корпоративных приложений в бизнес-интерфейсы, добавляя, что это единственный подход, который работает в масштабе.

Другим способом интеграции SaaS и не-SaaS корпоративных систем является интеграция данных. Forrester определяет интеграцию данных как возможность сбора, доступа и использования данных между различными источниками данных, местами и приложениями.

«Интеграция данных служит для различных целей — для ввода пакетов данных в озера и хранилища данных, для оркестровки конвейеров потоковых данных, для передачи событий от процессов и машин или для извлечения инсайтов», — говорит Мишель Гетц, вице-президент и главный аналитик компании Forrester.

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

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

Децентрализация интеграции

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

Одной из тенденций, наблюдаемых Forrester, является демократизация ИТ-интеграции, в первую очередь для ИТ-команд бизнес-направлений, а также для гражданских (не ИТ) интеграторов.

При выборе технологии для поддержки этого процесса Мутер рекомендует ИТ-отделам обратить внимание на интеграционные платформы как сервис (iPaaS), которые ориентированы на простоту использования и быстрое обучение.

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

Заглядывая в будущее ИТ-интеграции и того, как организации соединяют SaaS- и не-SaaS-приложения предприятия, Мутер прогнозирует, что генеративный ИИ изменит способы ИТ-интеграции: «Вместо того чтобы создавать интеграционный поток вручную, вы будете говорить iPaaS-продукту на простом человеческом языке, чего вы хотите добиться, и он будет создавать интеграцию за вас».

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

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