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

Мир SOA: общие тенденции

Западные аналитики отмечают, что SOA все еще не слишком широко распространена и внедряется только тогда, когда это действительно необходимо. Согласно исследованию, проведенному Nucleus Research Inc летом 2007 года, здравоохранительные и сырьевые компании имеют самый высокий уровень внедрения SOA: около 62% организаций из сферы здравоохранения и 48% из сырьевого сектора применяют сервисный подход. Самый низкий уровень использования SOA — в индустриальных и некоммерческих организациях: только каждая пятая из них использует эту технологию.

Исследование показало, что лишь 37% компаний, использующих SOA, окупили инвестиции в ее развертывание. В то же время продуктивность предприятий, внедривших SOA, увеличилась на 28%.

На вопрос, достигли ли компании бизнес-целей, которые послужили для них причиной внедрения SOA, 69 % опрошенных сказали, что достигнуты лишь некоторые из поставленных целей, а 15% заявили, что не достигли их совсем.

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

Исследование Nucleus Research обнаружило также, что максимум одна из трех компаний сейчас использует репозитории, регистры, центры компетенции SOA или другие инструменты, способствующие переходу к сервисно-ориентированной архитектуре. В среднем повторно используется лишь 32 % сервисов.

Переход к SOA является хорошей практикой для большинства компаний, но положительные в целом результаты омрачаются неожиданными провалами проектов и не оправдавшимися ожиданими, как показывает опрос InformationWeek, опубликованный в августе 2007 года. Десять процентов опрошенных сказали, что SOA и Web‑сервисы превысили ожидания их компаний, а 58% из 278 респондентов удостоверили, что их ожидания оправдались. Однако для 32% этого не произошло.

А ожидали они вот чего: повысить гибкость развития приложений хотели 77%, а модульность ПО — 70%; снизить стоимость — 59%; на лучшую интеграцию с бизнес-партнерами надеялись 53%, а на более оперативное представление новых продуктов на рынке — 40%.

Так почему же SOA разочаровала почти треть компаний? Основная причина — в её сложности. О том, что SOA скорее внесла в ИТ-систему еще большую сложность, чем упростила ее, сказали 58% опрошенных, а для 30% она оказалась более дорогостоящей, чем они рассчитывали. Кроме того, из тех, чьи ожидания не оправдались, 27% заявили, что SOA не смогла обеспечить необходимого уровня интеграции.

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

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

Если у нас внимание к SOA подогревается в основном отрицанием архитектур предшествующих поколений, то на Западе движение к сервисной ориентации основано не только на этом. Иными словами, там можно говорить не только о в определенной мере противоположных SOA традиционных архитектурах, но и о комплементарных концепциях, которые по новизне нередко ничуть не уступают SOA. Одной из них является пресловутая Web 2.0, постепенно из мира бытового использования Интернета проникающая в корпоративный. Отличие ее от традиционной Web-технологии прежде всего в том, что она рассчитана не только на совместную работу интернет-средствами, но и на активное формирование Web-ресурсов (не важно, общедоступных или же корпоративных) как таковых. Это в свою очередь требует насыщения нового интернет-пространства Web-сервисами, и хоть последние еще не отождествляются с SOA, все же они являют собой значительный фактор, склоняющий предприятие к сервисно-ориентированной архитектуре.

Еще одна заметная черта западного подхода, отличного от российского, состоит в попытке применения сопутствующих стандартов, дополняющих основные спецификации для Web-сервисов (за основные примем SOAP, WSDL и UDDI), на базе которых в большинстве случаев и строятся SOA-проекты. Этих спецификаций существует уже десятка три, они имеют ярко выраженный прикладной, а не системный контекст и касаются таких вещей, как обеспечение безопасности, гарантия доставки сообщений, осуществление транзакций, управление метаданными и пр.

И, наконец, тесно ассоциируемая c SOA технология корпоративного управления — Business Process Management (BPM). То, что SOA и BPM сейчас стоят рядом, становится ясно после самого беглого анализа западных интернет-ресурсов, в той или иной мере посвященных SOA. Касается это пока, правда, больше предложений поставщиков, нежели конкретных проектов (хотя и таковые уже есть), но зато действия вендоров здесь очень активны.

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

Ключевые показатели внедрения

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

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

Значительную роль начинает играть SOA в транспортной отрасли. Большой интеграционный проект на основе данной архитектуры под названием ZEUS был предпринят с 2003 года аэропортом Цюриха, который постоянно взаимодействует со 180 партнерами и ежегодно перевозит около 20 млн. пассажиров. Каждый день на основе Web-сервисов выполняется 50  000 обновлений в различных системах оперативного управления. Скандинавские авиалинии (SAS) также сделали ставку на SOA в 2002 году, и в настоящее время структуру интеграционного функционала там составляет примерно 70 выделенных web-сервисов. Ключевое значение придается SOA в информационной интеграции, сопровождающей объединение компаний Air France и KLM.

Онлайновый аукцион Ebay хранит более двух петабайт данных. Программисты компании уже создали свыше шести миллионов строк программного кода и каждые две недели в среднем добавляют ещё по сто тысяч строк, а версия программного обеспечения изменяется около 30 000 раз в неделю. На компанию работает множество программистских групп, использующих самые разные платформы и инструментальные среды разработки. И SOA в данном случае не только стала мостом между технологическими платформами, но и позволила компании быстро включать в процесс новые сервисы, например, расширяющие функциональность системы оплаты PayPal.

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

ИТ-инфраструктура кинокомпании Dreamworks Animation KCG состояла из двенадцати ERP-приложений. Разбиение их на сервисы и применение промежуточного ПО позволило ей многократно использовать компоненты. Одна форма авторизации сотрудников, например, применяется в двенадцати различных приложениях.

Производитель и дистрибьютор молочной продукции компания Dean Foods владеет 120 фабриками в США и Испании и имеет около 360 000 клиентов. Бизнес компании разделен на несколько относительно независимых подразделений, каждое из которых вело собственную базу данных о продукции со своими кодами и описаниями товара. Создание общекорпоративного процесса управления информацией позволило ста сотрудникам из 32 различных бизнес-подразделений пользоваться едиными данными, а время вывода новых продуктов на рынок сократилось с пяти дней до одного.

Теперь давайте исследуем опыт западных компаний по внедрению SOA более детально.

SOA в телекоммуникациях: урок от BT

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

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

BT построила сервисы вокруг Web-стандартов, включая WSDL, UDDI и SOAP. Но эти сервисы тесно взаимосвязаны с BEA WebLogic, сервисом сообщений IBM WebSphere MQ и другими элементами традиционной инфраструктуры. Некоторые из них являются новыми, а некоторые собраны из частей кода функционирующих в BT приложений, которых насчитывается около трёх с половиной тысяч.

Компания отдавала себе отчёт, что работа Web-сервисов со старыми приложениями окупится только при таком развитии ИТ, когда наследуемые приложения со временем будут заменены. За три года развития сервисной архитектуры BT в течение первого года остановила 250 систем, за второй год — 710 и в первом квартале третьего — ещё 260 систем. Если бы этого не произошло, компанию могло бы ожидать усложнение системы и как следствие — не сбывшиеся ожидания по сокращению её стоимости.

В результате BT и 400 клиентов, строящих свой бизнес на основе ее сервисов, смогли использовать инфраструктуру SOA. Это помогло компании сократить время вывода новой услуги на рынок с 270 до 90 дней. С тех пор как BT вступила на путь построения сервисов, 85% из них уже в работе, и корпорация надеется, что проект удастся закончить в 2009 году.

Опыт BT показывает, что SOA можно построить вовсе не одним только определенным путем. По данным опроса, проведенного InformationWeek, только 34% компаний используют BPM, а ESB — 30%. BT использовала BPM от BEA, но без развертывания ESB — вместо этого она интегрировала сервисы с помощью более старых технологий, таких как IBM WebSphere MQ. Что действительно имеет значение — так это способность идентифицировать и изолировать сервисы, интегрировать их с другими сервисами или наследуемыми системами, чтобы их можно было использовать снова и снова, добиваясь с их помощью сокращения стоимости и развития бизнеса. Слишком многие компании не доводят эти преобразования до конца.

SOA в логистике — Con-Way

Транспортная компания Con-Way начала свой путь к SOA еще в конце прошлого века и сейчас представляет собой наглядную иллюстрацию того, как эта архитектура может показать себя в работе. Созданная в 1997 году как «дочка» CNF — крупной транспортной корпорации, Con-Way использовала корпоративную информационную систему для управления ресурсами, биллинга, отслеживания заказов и подобных процессов. Это ограничивало гибкость организации и ее способность к быстрому реагированию на изменения рынка.

Первоначально имея в ИТ-штате шесть человек (сейчас численность ИТ-персонала составляет около ста сотрудников, включая программистов, архитекторов и системных администраторов), Con-Way решила больше полагаться на собственные силы, чем на родительскую компанию. ИТ-отдел прикинул, что переработка приложений на языке COBOL займет около пяти лет, при этом на гибкость особо рассчитывать не приходилось. Поэтому решено было развивать собственное приложение в виде отдельных компонентов, запускаемых пошагово, а не ждать, пока будет готова вся система, чтобы увидеть выгоды от ее использования.

Компания пригласила независимого консультанта — эксперта в области компонентной архитектуры и объектно-ориентированного программирования. Он показал, как разрабатывать компоненты, достаточно абстрактные для повторного использования.

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

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

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

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

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