Интеграционные платформы: молодые, но амбициозные.

У интеграционных технологий большое будущее, причём как в технологическом, так и в бизнес-ориентированном аспекте. Cервисно-ориентированный подход (SОА) обещает преодолеть разрыв между бизнесом и ИТ, а именно эта проблема стоит в числе главных в индустрии. Однако интеграционные платформы еще очень молоды и сейчас представляют собой весьма проблемную область.

Новая роль интеграции

«Исторически интеграционные технологии появились в территориально-распределенных или же гетерогенных ИТ-ландшафтах, для многих из которых была характерна кусочная, островковая автоматизация. Роль интеграции при этом была дополнительной, вторичной, — говорит Леонид Алтухов, директор по продажам программного обеспечения IBM EE/A. — Сейчас ситуация начинает меняться». Главных причин таких изменений можно выделить две.

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

Цена интеграции нескольких ключевых приложений (здесь имеется в виду и стоимость проектов, и обеспечение качества данных, и обслуживание получившейся системы) — это главная проблема. «В конце 90-х годов сменилась парадигма интеграции, — считает Мария Каменнова, генеральный директор «IDS Scheer Россия и страны СНГ». — Принцип «best of breed», в соответствии с которым для автоматизации отдельных задач или процессов выбираются системы лучшие в своем классе, а затем в рамках бизнес-процессов всего предприятия интегрируются с помощью систем «middleware», себя не оправдал: цена интеграции оказалась очень высокой. Пришло понимание, что функциональные возможности отдельных решений не являются стратегическим преимуществом, производители программного обеспечения догоняют лидеров в функциональной составляющей за 6—12 месяцев. Стратегическим преимуществом оказалась способность к интеграции, простой и соответственно недорогой».

Вторая причина — обеспечение гибкости и скорости развития. Ведь перечисленные выше проблемы можно решить внедрением единого приложения класса ERP. «Но замена разнородных ИС на единую ERP-систему не всегда оправданна, тем более что требует серьезных временных и материальных затрат, — таково мнение Алексея Галагана, руководителя дирекции интеграционных проектов консалтинговой группы «Борлас». — Быстро меняющиеся условия и задачи бизнеса диктуют необходимость немедленной работы с уже имеющимися системами, что наиболее эффективно в случае приведения этих систем к общему знаменателю — интеграционной платформе». Многих ИТ-директоров попытка уместить в бюджет все фантазии ответственных сотрудников просто заводит в тупик. «Например, в крупной компании есть три основных подразделения, и каждое имеет привычное ПО оперативного контура; всё более-менее работает по отдельности, но плохо увязано, синергетический эффект на нуле, — рассуждает Алексей Ковтунов, руководитель SAP-практики компании Verysell Enterprise ONE. — Ответственные сотрудники имеют уникальные взгляды на архитектуру и функциональость ERP-решения. В результате в силу равной весовой категории и сложной политической обстановки несколько лет продолжается грызня. Оставив надежду привести всё к единому знаменателю и сделать комплексный ERP-проект, а также чувствуя ускользающий бюджет и влияние, ИТ-директор делает ход конём: выбирает сложный и не всегда оптимальный интеграционный проект как путь к быстрым победам. И хотя сам ИT-директор вполне отдаёт себе отчёт, что данный проект может затянуться на годы, профиль этого проекта более программистский, в нём гораздо больше гибкости и можно лучше удовлетворить всех потребителей».
Хотя в вышеприведенном примере много юмора, но и очень велика доля истины. «Какова альтернатива использованию интеграционных платформ? — спрашивает Леонид Алтухов (IBM). — Встраивание интеграционных механизмов в интегрируемые приложения, то есть переписывание приложений таким образом, чтобы они умели взаимодействовать с внешними системами в правильном порядке, который отражает бизнес-процессы предприятия. Этот затратный и сложный путь приводит всю интегрированную систему в тупик, потому что при добавлении новых приложений, внесении изменений в уже существующие или в порядок их взаимодействия, то есть в бизнес-процесс, необходимо внести изменения во многие приложения всего комплекса. Ведь все приложения «жестко завязаны», и желание что-то изменить в одном месте требует множества изменений в различных частях системы. Это есть интеграция в «жестком» стиле, и это неправильно».

Именно недовольство существующими парадигмами построения информационных систем предприятия, как монолитными ERP-пакетами, так и подходом «best of breed», и вызвало к жизни новые архитектуры. В таком архитектурном кризисе и сформировалась новая тенденция рынка информационных технологий и изменилась роль интеграционных технологий в ИТ-архитектуре предприятия. Интеграционная платформа решает задачу взаимодействия приложений, минимально затрагивая сами приложения, «вынося» из них весь интеграционный функционал и предоставляя возможность гибкого изменения интеграционной логики внутри самой интеграционной платформы без большого вмешательства в интегрируемые системы. «Новая роль интеграции видна через призму сервисно-ориентированной архитектуры, — говорит Леонид Алтухов. — По мере продвижения парадигмы SОА интеграционные технологии, объединенные на уровне продуктов и стандартов в интеграционные платформы, становятся основой построения ИТ-систем. Идея SОА подталкивает к построению ИТ-комплекса в виде композитных (составных) приложений, набранных из более мелких компонентов-сервисов. Эти сервисы внутри композита интегрированы между собой. Следовательно, интеграция становится внутренней сущностью «большого» композитного приложения, а интеграционная платформа — неотъемлемой частью любого ИТ-ландшафта».

Эволюция интеграционных платформ

Понятно, что видя новую тенденцию рынка информационных технологий, компании-лидеры — SAP, IBM, Microsoft и Oracle — инвестировали немалые ресурсы в разработку таких платформ. Как же шло их развитие? «В развитии интеграционных технологий можно выделить две тенденции: развитие функционала и стандартизацию, — считает Леонид Алтухов. — Платформа программирования J2EE показывает четкую тенденцию поддержки стандартов, особенно значимых для SOA (например, BPEL, SDO, SCA). Параллельно активно развиваются межплатформенные стандарты в области Web-сервисов. Что касается функционала, то интеграционные платформы вобрали в себя не только технологии транспортного уровня, обеспечивающие надежную асинхронную связь между приложениями, но и возможности сложных преобразований передаваемой от приложения к приложению информации. Оформилась в виде отдельных продуктов и хореография работы приложений, позволяющая формализовать и автоматизировать её очередность, определяемую реальными бизнес-процессами. Современная платформа связывает надежным транспортом различные компоненты-приложения, устраняет «непонимание» между ними, преобразуя форматы сообщений, посылаемых приложениями, и позволяет отделить логику бизнес-процесса (хореографию) от логики приложения, построив в результате гибкий интегрированный ИТ-комплекс».

Очевидно, что интеграционные технологии развивались вместе с системами, которые они были призваны объединить. Поэтому история их развития отчасти определяется технологическими факторами. Так, с появлением баз данных появились и решения по репликации данных, а отказ от монолитных приложений и развитие телекоммуникаций сделали возможным появление технологий распределенной работы приложений. Однако нынешний этап развития интеграционных технологий большинство экспертов считает качественно иным. Связано это с тем, что нынешние технологии становятся все более ориентированными на поддержку архитектур, отражающих именно функциональные стороны бизнеса предприятий. Если раньше основной упор делался на интеграционные технологии как таковые, то теперь — на функциональные стороны этой интеграции. «Если еще пять-семь лет назад основную роль играли Web-интерфейсы, позже такая технология, как ESB-шины [Enterprise Service Bus] совместно с использованием Web-сервисов, то следующим шагом станет сервисно-ориентированная архитектура SOA, которая позволит собирать ИT-модули в модифицируемые бизнес-сервисы и перестраивать бизнес-процессы предприятия, как кубики, многократно объединяя их для построения новых цепочек», — говорит Герман Лутчак, руководитель отдела разработок департамента продуктов Oracle компании GMCS.

Куда они будут развиваться далее? «Интеграционные системы как средство и среда коммуникации между разрозненными решениями становятся всё более семантически наполненными, начинают оперировать отвлечёнными, абстрактными понятиями, унифицируются, заимствуют друг у друга языковые средства. Думаю, в ближайшее время они смогут блеснуть самостоятельной адаптацией и изучением поведения незнакомой системы коммуникации, работающей по известному принципу (голосовой, электронный), — делится своим мнением Алексей Ковтунов (Verysell Enterprise ONE). — По мере роста вычислительных возможностей связываемых систем будет непрерывно усложняться и язык их взаимодействия, обретая возможности для описания не только информации и её форматов, но и, например, отношения информационных систем друг к другу (дружественное, враждебное, нейтральное, хорошее)».

Молодые технологии

Однако времени на развитие у поставщиков ПО было совсем немного, от силы 3—5 лет. Интеграция приложений на базе платформ направление молодое, причем не только в России, но и во всем мире, подчеркивает Феликс Гликман, президент и генеральный директор компании Tops BI. Поэтому вопросы зрелости интеграционных платформ как продуктов пока еще остаются болезненными. Любому ИТ-специалисту известно: работающая версия — только третья. Это, к сожалению, верно практически для любых продуктов. Интеграционные платформы не исключение, полагает Тагир Яппаров, президент группы компаний «АйТи»: «Таковы родовые признаки индустрии — ПО выходит на рынок незрелым и дозревает на ходу. Мы это понимаем, у нас иллюзий нет: если великая компания начинает продвигать продукт, нам заранее известно, что он собой представляет вначале. Но мы знаем также, что через три года это будет уже нормальный продукт, имеющий удачные внедрения, и с ним будут работать ведущие клиенты, поэтому мы не ропщем и не даем своим технарям тормозить процесс».

Ситуация усугубляется объективной сложностью подобных технологий. Задачи интеграции могут быть самыми разными — как на уровне данных, так и на уровне приложений. Развитие интеграционных систем с начала нового века позволило осознать, что результатом интеграции является не только обмен информацией, но и, как следствие, возможность контроля над всеми процессами предприятия, управление ими и их мониторинг. «На сегодняшний день интеграция приложений в индустрии рассматривается в очень широком смысле этого понятия, — говорит Андрей Суслов, консультант московского представительства BEA Systems. — Интеграционные задачи подошедших к этому моменту предприятий очень различны. Поэтому интеграцию можно рассматривать на нескольких уровнях: на уровне данных, на уровне сервисов или же на уровне бизнес-процессов. Причем, как правило, задачи решаются не на одном, а сразу на нескольких уровнях. Для поддержки таких сложных процессов необходимо сложное программное обеспечение, покрывающее не только собственно функциональность, но и многие инфраструктурные моменты, такие как безопасность, масштабируемость, отказоустойчивость и т. д. Именно в силу необходимости обеспечения подобной инфраструктуры, присущей всем задачам интеграции, а также поддержки стандартов интеграционный слой выделяется в отдельную платформу».
Учитывая необходимый темп выхода на рынок, далеко не все из этих технологий разрабатываются компаниями с нуля. «Сегодня основные поставщики говорят об интеграционных платформах, сочетающих в себе средства интеграции разного уровня, — полагает Юлия Кудрявцева, заместитель директора по развитию бизнеса «SAP СНГ». — Важно, чтобы компоненты интеграционной платформы не конфликтовали друг с другом, а позволяли ускорять внедрение интеграционных решений. Однако нынешние интеграционные решения в компаниях могут представлять из себя спагетти, состоящие из различных средств интеграции: например, портал от одного поставщика, хранилище бизнес-информации от другого, брокер интеграции от третьего. А еще есть средства разработки, системы управления НСИ и так далее. Всё это вряд ли способствует снижению ТСО компаний. Вопрос заключается только в том, как основные ИТ-вендоры двигаются в этом направлении. Например, мы видим, что некоторые активно идут по пути покупки интеграционных решений. И получается, что зонтичный бренд «интеграционная платформа Х» объединяет в себе, например, более 25 различных (иногда пересекающихся по назначению) решений, 14 архитектурных комплексов, 5 конфликтующих workflow и т. д.».

Есть и другое мнение по поводу зрелости. «Сегодняшние интеграционные платформы — это продукт своего времени, полностью удовлетворяющий текущий спрос на мировом рынке, — считает Андрей Ходунов, ведущий специалист по программным решениям компании «Ай-Теко». — Конечно, пару лет назад они были менее совершенны, а ещё через пару лет будут более совершенны, но это означает лишь, что производители ПО стремятся следовать мировым тенденциям». «Сейчас SОА находится на острие стратегической мысли, поэтому понятен интерес к вопросу зрелости, — говорит Леонид Алтухов. — В среднем зрелость интеграционных инструментов на рынке не ниже зрелости программного обеспечения в целом, хотя и есть различия между платформами разных производителей, а внутри одной платформы существуют разные компоненты с различной историей развития. IBM вкладывает в развитие программного обеспечения для построения решений на основе SОА более 1 млрд. долл. в год. Сегодня корпорация ведет более 3000 проектов на основе SОА и имеет 100 тыс. обученных специалистов».

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

Очень важный аспект зрелости решений — возможность реализации сервисно-ориентированного подхода. «Не секрет, что основные игроки на рынке интеграционных решений заявляют о полной поддержке своими продуктами всех направлений интеграции, о полной поддержке сервисно-ориентированных архитектур, — продолжает Андрей Суслов. — Безусловно, это не является голословными высказываниями: вендоры прилагают длинные списки success stories по заказчикам в Америке и Европе. Однако реалии заключаются в том, что зачастую в основе современного сервисно-ориентированного подхода лежат унаследованные решения, возможно, даже не соответствующие современным стандартам, таким как J2EE. Конечно, на нижнем уровне в итоге все равно находятся системы обмена сообщениями (messaging), однако для реализации современной и полноценной SOA необходима также и поддержка специфичных для сервисов (и Web-сервисов) стандартов и технологий».

В целом опрошенные нами эксперты скорее подтверждают недостаточную степень зрелости интеграционных платформ. «На сегодняшний день такой монолитной интеграционной платформы, которая позволила бы решать все типы интеграционных задач одновременно, нет, — резюмирует Олег Оленин, менеджер проектов департамента ИТ-консалтинга компании «ФОРС — Центр разработки». — Так, если платформа основана на оркестровке Web-служб, то вряд ли в ней предусмотрены компоненты реализации ETL-решений. В целом возможности интеграционных платформ по технологическому обеспечению межсистемного взаимодействия стали значительно шире, но при этом по-прежнему недостаточно внимания уделяется решению задач управления мастер-данными и вопросам семантической интеграции. По всей видимости, решение, способное обеспечить поддержку интеграционных проектов по всем необходимым направлениям, будет разработано в ближайшие годы. Создается впечатление, что вендоры нам обещают именно это. В проектах, где применяется процессно-ориентированный подход, интеграционная платформа однозначно выступает в качестве ядра системы. Спрос на такое зрелое и универсальное «самодостаточное» решение будет особенно велик».

Молодые специалисты

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

Однако здесь есть существенные проблемы. Парадигма SОА предлагает новые роли специалистов, которые помогут «перебросить мостик» от ИТ к бизнесу и ускорить перевод потребностей руководителей на уровень реализации. Феликс Гликман полагает, что для комплексных интеграционных проектов необходимы очень редкие пока специалисты — архитекторы. «Мало людей, способных прийти в компанию, рассмотреть процессы, рассмотреть действующие системы и предложить им адекватную архитектуру интеграционного ядра. Это новая задача, и после появления спроса на нее должно пройти время, прежде чем вырастут кадры», — отмечает он.

«Действительно, специалистов по внедрению интеграционных платформ в России практически нет, — подтверждает Андрей Ходунов. — Конечно, человека с базовыми знаниями технологий XML, SQL, Java и т. д. можно обучить работе с интеграционными платформами и получить инженера начального уровня. Но в проектировании платформ не столько важна инженерная экспертиза, сколько техническая. Необходимо понимать принципы построения архитектур, основы бизнес-анализа, чтобы понять, как надо строить работы по проекту. Такое понимание очень важно для достижения конечного результата».

Появление таких специалистов требует инвестиций. Но вендоры как были продуктовыми, так и остаются, западные консалтинговые компании до сих пор представлены в России очень ограниченно, а западных интеграторов в российском понимании этого слова на рынке нет, считает Феликс Гликман. У российских же компаний опыта проектов такого класса еще просто не может быть. Однако если есть спрос, то и предложение будет: «В этом году мы уже создали у себя службу бизнес-архитекторов, причем не связанных с каким-то определенным продуктом», — отметил Феликс Гликман.

Рынок взорвался

Тем не менее пусть малый, но опыт таких проектов есть. Причем, судя по всему, сейчас ситуация с подобными проектами меняется кардинально. Рынок взорвался, подтверждает Тагир Яппаров, президент группы компаний «АйТи». «Об этом много говорили и раньше, но очень редко на такие проекты шли, — подчеркивает он. — Из области экзотики они становятся нормой, из сферы дискуссий, перспективного планирования масштабная интеграция постепенно переходит в практическую плоскость, и сейчас уже все крупные проекты строятся с учетом интеграции внутри них». «Еще два года назад российский заказчик слабо представлял, что такое интеграционные технологии, и чаще всего описывал их как совокупность протоколов для передачи данных вроде FTP, HTTP либо как синхронизацию данных в различных программах с помощью API или встроенных средств, — говорит Андрей Ходунов. — Но теперь приходит понимание комплексных средств интеграции приложений и их преимуществ».