От ROI до безопасности: 6 вопросов, на которые вам следует ответить, прежде чем внедрять SOA

На сегодняшний день сервис-ориентированная архитектура – наиболее обсуждаемое и наименее понятное явление в мире ИТ. Есть даже книга для “чайников”, посвященная SOA! Напомним, что SOA – это подход к построению ИТ-систем: она соединяет приложения сети посредством единого протокола обмена данными, тем самым позволяя организациям повторно использовать старое программное обеспечение, часто с помощью Web-сервисов. Исследования известной аналитической и консалтинговой компании Saugatuck Technology показали, что в следующем году более чем две трети ИТ-отделов полностью или частично внедрят SOA. Данная статья посвящена обсуждению шести наиболее актуальных вопросов, которые неизбежно возникнут у ИТ-отделов, решивших перевести предприятие на SOA-архитектуру.

1. Помогает ли SOA экономить (или зарабатывать)?

Ашок Кумар, директор по информационным сервис-ориентированным технологиям в компании Avis Budget Group, с уверенностью заявляет, что да, SOA действительно помогает экономить и зарабатывать. Сервис-ориентированная архитектура была частично внедрена в их компании 2 года назад с целью формирования новых каналов связи с партнерами. «Теперь партнеры могут вести с нами бизнес, не прибегая к услугам посредников…» - говорит Кумар. Таким образом, SOA сократила издержки и самой компании, и партнерам. Более того, благодаря SOA компания вообще не несет никаких расходов при поиске новых партнеров. Кстати, на поиск нового партнера теперь достаточно одного дня, ведь с SOA это означает всего лишь изменить конфигурацию сервиса, а не вносить неимоверные изменения в приложения, что могло длиться целый месяц, а то и дольше. Если раньше затраты компании на поиск новых партнеров составляли от 40000 до 50000 долларов, то теперь они снизились до 3000-4000 долларов. Любой компании неизбежно придется столкнуться с предварительными расходами (инвестициями), связанными с внедрением SOA, но специалисты в области ИТ утверждают, что эти затраты со временем окупятся.

Аналитик Джудит Гурвитц, автор нашумевшей книги «Сервис-ориентированная архитектура для «чайников» (“Service Oriented Architecture for Dummies”), также придерживается мнения, что SOA нельзя рассматривать с позиций краткосрочного инвестирования: «Это такой вид технологий, который нацелен на повторное использование и обеспечение слабосвязанности компонентов… Не следует ждать быстрого возврата инвестиций, поскольку окупятся эти технологии лишь тогда, когда начнутся те самые перемены, ради которых они, собственно, и были внедрены». По мнению Джудит Гурвитц, традиционные подходы к построению ПО предполагают, что вы начинаете с нуля, а потом разрабатываете нечто новое для решения определенной проблемы. SOA же наделяет бизнес необыкновенной гибкостью, позволяя ему чутко и мгновенно реагировать на важные изменения. SOA может не окупиться спустя месяцы после ее развертывания. Но как только появится случай, бизнес мгновенно и чутко отреагирует на изменения благодаря тому, что SOA обеспечит необходимое именно для данной ситуации ПО.

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

Как замечает Лэрри Фултон, старший аналитик компании Forrester Research, дать ответ на этот вопрос очень нелегко: «Допустим, 5 лет назад я решил построить новую систему управления предприятием (ERP-систему), и сейчас я тоже хочу построить новую ERP-систему, только для этого решил использовать SOA. Как и в прошлый раз, я трачу на проект и ПО 5 млн. долларов. Получается, что я трачу 5 млн. долларов на SOA? А вот и нет, 5 млн. долларов я трачу на бизнес-решение».

Майк Вест из аналитической и консалтинговой компании Saugatuck Technology объясняет, что существует два вида возврата инвестиций в SOA. Первый связан с тем, что ИТ получает возможность снизить затраты на обеспечение предприятия необходимыми сервисами. По-мнению Веста, пока общая тенденция внедрения SOA такова, что предприятия в основном находятся на начальной стадии внедрения, связанной с большими затратами, и только 10-15 % предприятий начали ощущать преимущества SOA, которые выражаются в сокращении издержек. И совсем пока еще малая толика предприятий уже получила возможность улучшить свои доходы за счет использования уже внедренной сервис-ориентированной архитектуры.

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

В качестве примера можно привести крупнейшую в мире дебетовую электронную платёжную систему PayPal, которая с октября 2002 года является подразделением компании eBay.

По словам вице-президента по основным технологиям Мэтью Менгеринка, PayPal использует SOA для того, чтобы обеспечить внешних разработчиков теми инструментами, которые им необходимы для того, чтобы связать онлайновых розничных торговцев с системой, отвечающей за обмен денег между покупателями и продавцами. На данный момент PayPal использует около 16 интерфейсов программирования приложений (API) и обеспечивает инструментарием 240000 разработчиков. «Другие могут строить что-то свое на основе PayPal-а, мы тратим на это деньги, но, предлагая «запчасти», мы получаем в результате больше клиентов», - говорит Мэтью Менгеринк.

2. Почему так сложно найти работников, обладающих навыками, необходимыми для работы в SOA-среде?

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

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

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

Джудит Гурвитц соглашается с Кумаром, говоря, что даже если вам и удалось нанять действительно опытных и компетентных специалистов в области SOA, вы не застрахованы от того, что они будут пытаться выполнить большой объем работ за короткий промежуток времени. Энтузиасты иногда любят «строить из себя героев». Команда молодых разработчиков может поддаться соблазну нарушить правила и начать программировать самостоятельно, пытаясь создать новые возможности, опередив и переплюнув конкурентов. Разумеется, такие инновации действительно важны для получения статуса лидера на рынке, однако, как утверждает Гурвитц, следует помнить одно «но»: инновации и творчество всегда должны быть под контролем.

3. Неужели Microsoft не в курсе того, что существует такая замечательная альтернатива как SOA?

Лэрри Фултон убежден, что Microsoft в курсе, хотя их стратегия и немного непонятна. По его словам, в компании Microsoft «осознают, что SOA приобрела большое значение на рынке». На данный момент от поставщиков, которые серьезно занимаются SOA, ожидают, что они предложат устойчивую корпоративную сервисную шину (ESB).

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

Однако, как замечает Лэрри Фултон, в отличие от IBM и BEA, Microsoft как будто не стремится на этом заработать. Позиция Microsoft отличается тем, что она не призывает купить ESB, а предлагает продукты, с помощью которых эту ESB можно построить. В компании Microsoft даже обсуждалась идея создания пакетов-акселераторов, облегчающих построение такой сервисной корпоративной шины на основе таких продуктов, как, например, сервер BizTalk, поставляемый самой Microsoft. Напомним, что сервер BizTalk – это сервер, управляющий бизнес-процессами, он располагает инструментарием, позволяющим проектировать, разрабатывать и развертывать корпоративные бизнес-процесы, а также управлять ими.

Гурвитц подытоживает мысль Фултона, говоря, что интеграционные технологии, заложенные в сервере BizTalk, - это та альтернатива, которую предлагает Microsoft корпоративной сервисной шине.

В своей книге Джудит Гурвитц перечисляет 7 других продуктов компании Microsoft, которые поддерживают SOA. Среди них есть сервер Microsoft Windows Server – платформа инфраструктуры, использующаяся для обеспечения связи между приложениями, сетями и Web-сервисами; Microsoft.NET – среда разработки, использующаяся для построения приложений и Web-сервисов и, наконец, Windows Communication Foundation – набор технологий, обеспечивающих сообщение между компонентами SOA и упрощающих разработку и запуск систем.

Таким образом, Лэрри Фултон приходит к выводу, что Microsoft все же, по большому счету, проявляет интерес к поддержке Web-сервисов и сервисных интерфейсов.

Позиция Майка Веста несколько отличается: «Не думаю, что Microsoft действительно осознает важность SOA… Деятельность компании Microsoft никак не пересекается с SOA… SOA основывается на открытых стандартах, что делает продукты, предлагаемые разными вендорами, в большей или меньшей степени взаимозаменяемыми. А позицию компании Microsoft можно назвать «ориентированной на саму себя», т.е. мы имеем Microsoft-ориентированный подход к Web-сервисам».

Джудит Гурвитц же считает, что на данном этапе компания Microsoft прекрасно отдает себе отчет в том, что такое SOA. Создавая такие вещи, как сервисная Интернет-шина (ISB), Microsoft расширяет возможности сервисной шины и создает ее в таком виде, в котором она позволит удовлетворять потребности партнеров, находящихся за пределами корпоративного брандмауэра. Однако Microsoft пока не дает достойного ответа на решение таких вопросов, как управление или предоставление потребителям механизма, позволяющего размещать собственные индивидуальные сервисы. «У них есть интересные задумки, но не думаю, что они все это уже хорошо продумали»,- говорит Джудит.

4. Каким образом SOA влияет на оптимизацию сети и управление?

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

Якобс также замечает, что способ измерения эффективности работы сети тоже может измениться. Метрическая система измерения пропускной способности необъективна, потому что каждый процесс генерирует множество взаимодействий между различными компонентами приложений. Поскольку каждое из этих взаимодействий само по себе задействует мало данных, целесообразно измерять скорость выполнения глобальной транзакции и скорость реакции.

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

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

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

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

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

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

5. Меняются ли требования безопасности, если на предприятии внедрена SOA?

Руководители ИТ-отделов компании Avis Budget думали, что безопасность – это не более чем локальная проблема, однако после внедрения SOA оказалось, что эта одна из самых главных проблем, с которыми им пришлось столкнуться.

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

Получается, что основная проблема состоит в управлении идентификацией (Identity management), т.е. обеспечении безопасности корпоративной информации самого высокого уровня, иными словами – в контроле за идентификацией лиц, получающих доступ к конфиденциальной информации.

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

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

Гораздо удобнее в этом отношении федеративная идентификация, основанная на доверии источнику утверждений и языке SALM. Запросы информации по контролю за доступом могут быть закодированы в запросы браузера или включены в транзакции Web-сервисов.

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

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

«На нашей Web-странице очень много уязвимых мест. Вы регистрируетесь на нашем сайте, я теперь знаю ваши имена, знаю, кто вы, и взимаю с вас небольшую пошлину за возможность со мной связаться [т.е. за пользование нашей SOA]. Таким образом, я имею дело с достаточно узким кругом людей. И решить эту проблему гораздо проще, чем если бы кто угодно мог зайти на сайт www.PayPal.com и начать атаку.

6. Есть ли у SOA минусы?

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

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

На сегодняшний день, как отмечает Фултон, мы имеем около 15 вендоров, предлагающих действительно надежную корпоративную сервисную шину, однако на рынке ощущается явная нехватка качественных технологий по управлению данными.

Другим слабым местом SOA является финансирование. Как справедливо замечает Кумар, не смотря на то, что SOA со временем повышает прибыль бизнеса и снижает издержки, очень нелегко убедить спонсоров вложить в нее средства. «Все основывается на модели финансирования, подразумевающей финансирование проекта, в которой каждый финансируемый проект должен оправдать вложенные в него средства (ROI). И довольно непросто объяснить людям, осуществляющим финансирование, что в своих расчетах необходимо выходить за рамки отдельно взятых проектов».

Джудит Гурвитц видит слабое место SOA не в технологиях, а в людях, которые их разрабатывают. Особенно это проявляется в ситуациях, когда разработчики не учитывают интересы бизнес-отделов, не думают о том, какие сервисы нужны бизнесу. «Вы создаете 10000 сервисов, только они слишком гранулярные и к ним сложно получить доступ».

Лэрри Фултон также отмечает, что клиента также может сбить с толку обилие предлагаемых технологий для поддержки SOA. «Есть всевозможные ESB, продукты, обеспечивающие управление SOA, ПО, управляющее Web-сервисами, акселераторы для Web-сервисов, межсетевые интерфейсы и многое другое. Вопрос в том, что же мне действительно нужно? И, разумеется, на него существует только один ответ: «смотря по обстоятельствам». Однако очень многие выбирают такой подход: «Перечислите все, что мне необходимо приобрести, чтобы я мог сразу же и быстро внедрить у себя SOA». Это в корне неверный подход, поскольку вы можете потратить немалые деньги на то, из чего вы не сможете извлечь макимум необходимых вам преимуществ».

По материалам JavaWorld

Комментарии