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

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

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

Более того, руководство считает, что трудности, возникающие при интеграции систем, — всего лишь очередная попытка ИТ-отдела оправдать свою медлительность, негибкость и неспособность решить поставленные задачи.

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

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

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

Безотлагательность и сложность решения этого вопроса отражена в исследовании «Положение ИТ-директора». В 2002 году, когда было проведено первое исследование, интеграция была признана наиболее важной технологической проблемой, стоящей перед ИТ-руководителем. (То же повторилось и в 2004 году.) При этом претензии генеральных директоров к ИТ-службе оставались неизменными: высокая затратная часть, медлительность и негибкость.

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

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

Но и самих ИТ-руководителей такое состояние дел устраивает мало.

Как интеграционный слой поможет решить проблемы

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

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

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

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

Обмен сообщениями может быть использован в качестве ИТ-решения, но никак не является средством достижения стратегических целей, стоящих перед компанией. У информационных технологий очень долго не было так называемого «высшего предназначения», то есть стратегии применения. Теперь же эта стратегия выработана и в ее основе лежит концепция, сформулированная еще во времена объектно-ориентированного программирования в 80-х годах. Эта концепция фомулируется следующим образом: технология должна быть скорее элементом бизнес-процесса, такого как, например, «получение кредита» или «поиск клиента», нежели некой загадочной системой вроде ERP или CRM.

Объектное программирование

Сервис, применяемый в телекоммуникационной компании Verizon, называется «get CSR» (получить клиентскую запись) и представляет собой сложный комплекс действий, выполняемых программным обеспечением. Для доступа данного сервиса к более чем 25 системам, находящимся в четырех информационных центрах компании Verizon по всей стране, используется инфраструктура обмена сообщениями. До создания сервиса «get CSR» разработчикам Verizon приходилось выстраивать системные маршруты от каждого нового приложения ко всем 25 системам, добавляя все новые и новые подсоединения к уже существующей сети.

Теперь с внедрением «get CSR» разработчики создают единый маршрут к аккуратно выстроенному интерфейсу, который взаимодействует с самим сервисом с помощью простого протокола доступа (SOAP). Именно по этому маршруту сведения о клиентах из всех

25 систем поступают в новые приложения. Таким образом, каждое обращение к данному сервису позволяет сэкономить разработчикам месяцы, а то и годы.

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

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

Тоби Редшоу, вице-президент по вопросам корпоративной ИТ-стратегии, архитектуры и электронного бизнеса компании Motorola услышал нечто подобное от своей 80-летней матери, когда попытался объяснить ей принцип построения единого ИТ-каталога бизнес-сервисов. «После того как я закончил свои объяснения, она сказала: «Разделение труда на производстве появилось 200 лет назад. Почему же ты так долго медлил?”»

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

Процесс интеграции не только становится стратегической задачей, но и позволяет в значительной степени сократить финансовые (согласно оценкам компании Gartner, как минимум на 30 %) и временные затраты. По отзывам самих участников процесса экономия действительно превышает все ожидания. Редшоу из компании Motorola утверждает, что затраты на интеграцию сократились в десять раз по сравнению с прежними показателями. Шадман Зафар, старший вице-президент по вопросам архитектуры и электронных сервисов компании Verizon, говорит, что его каталог сервисов недавно позволил избежать создания группы специалистов для размещения заказов по телефону, так как все необходимые сервисы уже были готовы. «Если бы мы работали по системе точечной интеграции, нам бы пришлось создать центральную группу разработчиков для осуществления общего процесса интеграции нескольких систем и несколько местных группы, которые бы работали над каждой отдельной системой. В данном случае у нас была всего лишь одна группа, которая занималась исключительно тестированием маршрута передачи данных». Таким образом, данное решение позволяет не только сэкономить время и ресурсы, но и улучшить качество новых продуктов, так как тестирование теперь становится не последним препятствием в утомительном процессе внедрения нового приложения, а, наоборот, его целью.

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

Централизация руководства

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

«SOA не является технологией. Это всего лишь структура, своего рода шаблон, и если вы не будете полностью контролировать ее внедрение и применение в организации, вам никогда не удастся выстроить настоящую сервис-ориентированную архитектуру. Существуют миллионы вариантов построения промежуточного уровня в корпоративной системе, но из них вам необходимо выбрать один, оптимальный», — говорит Рик Свини, главный архитектор Blue Cross and Blue Shield штата Массачусетс.

Например, компания Verizon, офисы которой находятся друг от друга на приличном расстоянии, располагает единой бизнес- и ИТ-моделью для всех подразделений, благодаря чему в компании никогда не возникало конфликтов при внедрении промежуточного уровня или реализации стратегии SOA. При разработке корпоративной стратегии одна из главных задач заключалась в ликвидации многообразия систем, возникшего после слияния с другими телекоммуникационными компаниями, такими, как GTE и Nynex.

И эта задача была не из легких. Когда в 2001 году команда Зафара начала выбирать наилучший вариант из имеющихся систем, им пришлось просмотреть каждую клавишу и ниспадающее меню в каждом приложении (которых всего было почти 2900) для того, чтобы найти функциональные элементы, которые могли бы быть использованы при разработке сервиса. Из тысяч функций было выбрано где-то между 200 и 500, необходимых для более чем 90 тыс. транзакций, выполняемых компанией. Затем при тщательной проверке инфраструктур было выявлено от 5 до 25 прототипов каждой функции. Зафар остался доволен проделанной работой, так же как генеральный директор Шайган Керадпир и другие руководители Verizon, которые на деле убедились в эффективности стратегии внедрения промежуточного слоя.

Проблема с разработчиками

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

С первого взгляда разработка сервиса — далеко не самое простое решение. Помимо всего прочего необходимы определенные затраты времени для создания интерфейса — того самого элемента, который наглядно демонстрирует, какую функцию выполняет данный сервис и с какими системами он взаимодействует. Удачный интерфейс подобен хорошему другу: прост в общении и не выказывает ни намека на сложную историю взаимоотношений. «Хороший сервис умеет сам определить своего пользователя и представиться ему», — говорит Джеф Глисон, директор по ИТ-стратегиям отдела финансовых рынков компании Transamerica Life Insurance and Annuity. — Интерфейс интеграционного сервиса должен быть интеллектуальным и коммуникабельным».

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

Однако при построении данных интерфейсов разработчикам требуется определенная мотивация. «Все думают только о том, как бы поскорее запустить новое приложение в работу, — говорит Зафар из Verizon’s. — Мало кто заботится о развитии уже существующих систем. И даже если их прижать к стенке, они вряд ли будут в состоянии разработать наилучший возможный интерфейс, а сделают ровно столько, чтобы можно было сказать, что работа выполнена».

Зафар был первым, кто создал централизованную методологию разработки и хранения сервисов. Его принцип взаимодействия с разработчиками прост: он делает обзор существующей архитектуры в начале каждого проекта (чтобы взять с них слово, что во время работы над проектом они не только будут создавать новые сервисы, но и применять существующие) и по его завершении (чтобы выяснить, кто из разработчиков смог сдержать свое слово). Когда Зафар приступил к разработке каталога сервисов (известного в компании Verizon под названием «Рабочая панель ИТ») в 2001 году, многие разработчики так и не смогли выполнить свое обещание. «Нам даже пришлось свернуть несколько проектов, — говорит он. — Люди же смогли уяснить, что для успешной работы им необходимо использовать практические достижения, имеющиеся в компании».

По мере роста каталога в ход шли более привлекательные средства мотивации. Несмотря на то, что методология разработки имеет жестко централизованный характер, Зафар говорит, что самые удачные предложения по улучшению качества работы, поступающие от сотрудников, учитываются при определении общей методологии. На соответствующем Web-сайте Зафар регулярно выкладывает данные по наиболее часто используемым сервисам и приводит имена их разработчиков. Кроме того, Verizon предоставляет внешним партнерам доступ к некоторым своим Web-приложениям, поэтому шансы отдельного разработчика прославиться не только внутри своей компании, но и за ее пределами значительно возрастают. «Мы используем принцип гласности, — говорит Зафар. — Люди будут гордиться тем, что их разработки используются другими».

Однако перед тем как отдавать сервисы в пользование другим компаниям, необходимо удостовериться, что произведенный продукт является жизнеспособным и не приведет к сбоям в работе своих же приложений и процессов. (Это может произойти, например, когда сервис, предназначенный для выполнения 10 тыс. транзакций в день, подключается к приложению, выполняющему более 20 тыс. транзакций.) Централизованная структура управления не очень-то приветствуется разработчиками, однако она является гарантией того, что вся работа выполняется качественно и в соответствии с принятыми в компании стандартами. К этому Зафар еще добавляет гарантии уровня услуг, включающего предельное количество выполняемых транзакций, скорость выполнения транзакции, сроки доступности сервиса, а также стоимость предоставляемых услуг. «Пока в вашей компании не будет выстроена четкая структура разработки и внедрения, никто не будет воспринимать ваши сервисы как ключ к решению стратегических задач, — говорит Зафар. — Именно поэтому даже сейчас во многих компаниях SOA используется крайне неэффективно».

Подходит ли вам интеграционный уровень?

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

«Все расхваливают SOA как панацею, — рассказывает Ли Джонс, вице-президент по ИТ и ИТ-директор компании Stratex Networks, производителя беспроводного телефонного оборудования. — Идея глобального интерфейса до сих пор представляется мне сомнительной. Я не рассматриваю это решение как средство унификации моих приложений, потому как все мои системы работают бесперебойно». Джонс говорит, что ему удалось сократить расходы на интеграцию и повысить гибкость за счет интеллектуального промежуточного оборудования и минимизации сложных нестандартных приложений. Тем не менее он говорит: «Если у меня возникнут проблемы с интеграцией, SOA вполне может стать хорошим решением. Я буду рад, если мои сомнения окажутся напрасными».

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

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

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

Последние шаги

Для каждого бизнес-процесса существует своя отправная точка. Такие точки называются событиями. Например, можно запрограммировать, что при определенном событии региональному сервисному представителю будет отправлено по электронной почте уведомление («чтобы сообщить о том, что на данный момент его район находится вне зоны обслуживания»), либо запустится определенный сервис («найти новый номер»). События, как, впрочем, и сервисы, проще описать на деловом, нежели на техническом языке.

Если сервисы отражают конкретные бизнес- функции, то события определяют условия, при которых данные функции выполняются. По мнению Дэвида Лукхэма, заслуженного профессора в отставке по техническим исследованиям Стэнфордского университета и пионера событийно-ориентированного программирования, бизнес-процессы во многих компаниях используются крайне нерационально. Истинная ценность сервис-ориентированных процессов становится очевидна только при их соответствии событиям, происходящим в компании. По прогнозу Роя Шульта, аналитика компании Gartner, эти возможности начнут более активно использоваться в 2007 году, когда станут появляться стандарты для так называемого «комплексного обмена сообщениями о событиях».

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

Данная модель уже используется поставщиками программного обеспечения в управлении бизнес-процессами (см. статью Бена Уортена «Был бы ботинок, а клей найдется?!», Директор ИС, № 3 за 2005 год). Однако доступные пакеты еще не в состоянии обеспечить полную передачу управления SOA в руки бизнес-руководителей.

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

«В процесс разработки новых решений мы хотели бы наладить со своим руководством диалог. Традиционный подход: “Скажите, что вам надо, и мы это сделаем” становится пережитком прошлого», — говорит Редшоу.

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

Эволюция интеграции

Четыре стадии готовности

1. Точечная интеграция

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

2. Обмен сообщениями

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

3. Сервисы

Популярность этой концепции приходится на 80-е годы, а это было время развития объектно-ориентированного программирования. Свое перерождение она пережила в наше время, с внедрением Internet-стандартов и Web-услуг, а также усовершенствованием промежуточного ПО. Идея данной стратегии проста: технология должна быть скорее элементом бизнес-процесса, такого, как, например, «получение кредита» или «поиск клиента», нежели некой загадочной системой вроде ERP или CRM. Как правило, сервис представляет собой комплекс сокрытых под сложным интерфейсом различных приложений и данных, позволяющий легко соединять несколько сервисов друг с другом. Кроме того, созданный элемент критически важного бизнес-процесса может быть использован неоднократно при построении других процессов, что значительно сокращает время разработки. У разработчиков снова появляется гибкость, которой они располагали при точечной интеграции; ссылки, создаваемые теперь в оптимальном случае на основе Web-сервисов, могут легко удаляться и восстанавливаться. Более того, при таком подходе происходит внедрение сервис-ориентированной архитектуры (SOA): ИТ-отдел организует архив сервисов, которые разработчики могут использовать (и, что более важно, использовать неоднократно) для построения новых приложений и технологических процессов.

4. Бизнес-конфигурации

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

Трудности с Web-услугами

А вы смогли перевести критически важные для вашей компании транзакции в такую неустойчивую среду, как Web?

Некоторые ИТ-руководители спят и видят, как бы избавиться от всех своих поставщиков интеграционных решений и их инфраструктур обмена сообщений, заменив последние на бесплатные стандартные Web-сервисы. Это бы сразу же сняло такие извечные проблемы, как несовместимость платформ, высокая стоимость программного обеспечения и отсутствие связи с поставщиком 24 часа в сутки. Однако в данном случае ограничения все же есть. Они связаны со стандартами и транспортными системами, используемыми для осуществления Web-сервисов, а именно с самим Internet или, если быть более конкретными, протоколом HTTP.

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

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