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

А при чем здесь интеграция? Если какой-то этаж корпоративной архитектуры построен ненадежно, то все вышележащие будут еще хуже, ведь качество сервисов, получаемых бизнесом на самом верхнем уровне, зависит от всех нижележащих этажей архитектуры предприятия. Это значит, что качество информации отражает и качество архитектуры предприятия, а с архитектурой ИТ у нас в стране далеко не все так хорошо, как хотелось бы. Поэтому, прежде чем штурмовать вершины интеграции, внедряя новые технологии, стоит проанализировать готовность к ним архитектуры, тем более что в технологиях оценки недостатка нет. Можно рекомендовать модель зрелости архитектуры предприятия OMB Enterprise Architecture Assessment Framework, модель зрелости Гартнера (Gartner IT Score maturity assessment for enterprise architecture) и расширенную модель зрелости (Extended Enterprise Maturity Model) Института разработки архитектуры предприятия (Institute For Enterprise Architecture Development).

Качество архитектурного слоя определяется качеством интеграции в этом слое. В частности, от качества интеграции данных напрямую зависит качество данных, поэтому интеграция вправе претендовать на внимание и уважительное отношение. Однако для нас до сих пор  EDI (Electronic Data Interchange) [1], которому больше 40 лет, продолжает оставаться передовой технологией интеграции данных, и опасность такого положения вещей мы до конца еще не уяснили.

Рассмотрим теперь, что же обещают нам новые технологии с точки зрения интеграции?

Интеграция облачных сервисов. Здесь можно выделить горизонтальную и вертикальную интеграцию (рис. 1) сервисов на одном или различных архитектурных уровнях. В ситуации, когда компания использует, например, услуги провайдеров IaaS и SaaS, первый из которых предлагает хранение данных, а второй — их обработку, необходимо предусмотреть интеграцию их сервисов. Параметры интеграции определяются SLA (Service Level Agreement — соглашение об уровне обслуживания) соответствующих сервисов, которые обычно являются приложениями к договорам. При этом необходимо помнить, что SLA нижележащего архитектурного уровня всегда должно быть строже, чем SLA вышележащего, поскольку при обработке инцидентов необходимо учитывать временные потери на передачу информации между уровнями [2].

 

Рис.1. Вертикальная интеграция
Рис.1. Вертикальная интеграция

 

Поскольку сервисы предприятия тесно связаны друг с другом, а двойной ввод данных всегда приводит к существенному ухудшению качества информации, то жизненно необходима горизонтальная интеграция (рис. 2) — интеграция сервисов на одном архитектурном уровне. Кроме того, сервисы могут взаимно использовать друг друга или в виде коллажа формировать на лету новый синергетический сервис. Организовывать горизонтальную интеграцию на уровне передачи файлов Excel, как это сегодня делается чаще всего, очень опасно — приходится осуществлять строгий контроль версий и порядка обработки при сбоях. Такой контроль при интеграции сервисов в модели публичного облака осложняется тем, что за отдельные сервисы отвечают разные организации, обычно даже не связанные договорными отношениями. Контролировать такую интеграционную среду будет очень сложно, практически невозможно.

 

Рис. 2. Горизонтальная интеграция
Рис. 2. Горизонтальная интеграция

 

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

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

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

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

Семантическая и онтологическая интеграция данных. Для того чтобы интеграция заработала, необходимо предусмотреть семантическое и онтологическое сочетание данных, позволяющее интегрировать данные одной природы, но разной структуры. Это означает, что структура данных — семантика, позволяющая интерпретировать их соответствующим образом, — должна стать их неотъемлемым компонентом. Это же относится к качеству данных, так как оперировать данными, не зная их качества, опасно и бесполезно. Возможно, такой тип интеграции будет развиваться в направлении OWL (Web Ontology Language), языка описания онтологий для веб-документов и веб-приложений. Не исключено, что появится новое направление систем описания данных на базе XML или на SGML.

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

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

***

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

Литература

  1. Артак Оганесян. Модели и инструменты интеграции // Открытые системы.СУБД. — 2002. — № 11. — С. 42–48. URL:http://www.osp.ru/os/2002/11/182095 (дата обращения: 20.10.2014).
  2. Марина Аншина. Ландшафтный дизайн ИТ // Открытые системы.СУБД. — 2012. — № 8. — С. 24–27. URL:http://www.osp.ru/os/2012/08/13019120 (дата обращения: 20.10.2014).

Марина Аншина (Anshina@mail.ru) — председатель Комитета по стандартам, Российский союз ИТ-директоров (Москва).