"Многие современные ИС уже являются SOA-совместимыми"

Мы продолжаем обсуждение проблем SOA с российскими заказчиками (см.www.pcweek.ru/themes/detail.php?ID=110517). На сей раз на вопросы обозревателя PC Week/RE Андрея Колесова отвечает Ярослав Медокс, директор департамента развития информационных систем банка “Ренессанс Капитал”.

PC Week: SOA — это один из подходов к созданию ИТ-систем и реализации ИТ-проектов или это общий путь развития корпоративных ИТ-систем на современном этапе?

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

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

PC Week: Есть ли критерии, по которым (хотя бы условно, на качественном уровне) можно было бы отличить SOA-проект от не-SOA?

Я. М.: Если говорить о проектном подходе как таковом, то я бы не стал отличать SOA-проекты от не-SOA. Принципы управления проектами везде одинаковы. Речь может идти только о неких принципиальных технических отличиях. Например, можно сказать так: “Если вы занимаетесь интеграцией приложений и мыслите в категориях сервисов многоразового использования, единообразно используемых в разных бизнес-процессах, то определенно есть основания полагать, что вы строите SOA”.

Простым внешним признаком, по которому можно отличить SOA от не-SOA, является применение сервисной шины предприятия. ESB — это фундамент SOA, среда, в которой обеспечивается унифицированный доступ к сервисам. Для этого приходится решать задачи трансформации протоколов, форматов сообщений, маршрутизации сообщений и т. д. Если все это присутствует при построении системной архитектуры — да, мы имеем дело с SOA-проектом. Следующий уровень зрелости SOA — использование движков управления бизнес-процессами (BPM), которые обеспечивают компоновку, или “оркестровку”, сервисов в логической последовательности, соответствующей реальному автоматизируемому бизнес-процессу. Наличие таких систем (например, IBM Websphere Process Server) для управления сервисами — также очевидный признак SOA-проекта.

PC Week: В чем преимущества и недостатки (трудности) SOA-проектов?

Я. М.: Думаю, имеет смысл говорить не о преимуществах и недостатках конкретных SOA-проектов, а о SOA как основе создания и развития информационной системы предприятия в целом. В такой постановке вопроса главное преимущество SOA — это гибкость и скорость внедрения изменений, связанных с повышением темпа вывода новых продуктов (в том числе услуг) компании на рынок, что является ключевым вопросом для бизнеса. При этом следует понимать, что перечисленные преимущества достижимы не с первым бизнес-проектом, разрабатываемым в рамках SOA. Реальный эффект получается, когда уже создан некоторый фундамент в виде ESB, подключено не менее трех систем, определено несколько базовых сервисов. Другими словами, начальные инвестиции в построение SOA велики, не каждая организация готова пойти на такие расходы ради отдаленной выгоды. Это я бы отнес к недостаткам, затрудняющим инициацию SOA-проектов.

PC Week: Можно ли сформулировать общие рекомендации: когда SOA нужно применять обязательно или желательно и когда SOA нельзя применять ни в коем случае?

Я. М.: Если необходимо онлайновое взаимодействие трех и более систем в рамках какого-то ключевого бизнес-процесса — это первый повод задуматься о SOA. Однако если процесс стабилен, не подвергается изменениям при расширении бизнеса, тогда можно повременить. Говорить же в жестких формулировках, на мой взгляд, не следует вообще. Уверен, есть организации, которые предпочтут разработать десятки point-to-point-интерфейсов и в дальнейшем поддерживать их. На начальных этапах это точно будет стоить дешевле. Кроме того, сами вендоры интеграционного ПО считают, что в реальной жизни, конечно, есть альтернативы SOA. Это только подчеркивает тот факт, что нет жестких критериев для внедрения SOA или отказа от нее.

Если же организация нацеливается на рост бизнеса, на вывод многих сложных (комбинированных) продуктов на рынок, реальной альтернативы SOA пока не видно.

PC Week: Предполагает ли SOA более активное участие бизнеса в планировании и в реализации ИТ-проектов?

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

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

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

SOA не имеет самоценности. Она ценна преимуществами, которые приносит и которыми нужно умело пользоваться для того, чтобы создавать “добавленную стоимость” (added value) для компании.

PC Week: Изменяется ли в случае SOA соотношение участия в реализации проекта ИТ-подразделения заказчика и внешних исполнителей (консультантов, интеграторов)?

Я. М.:  В плане отношений с исполнителями нет никакого отличия SOA-проектов от остальных. Можно лишь судить о наличии или отсутствии квалифицированных специалистов у заказчика и о том, имеется ли у него стратегия в области аутсорсинга. Все новое, в том числе и SOA, требует специфической экспертизы. Обычно сначала опыт накапливают компании-подрядчики, но со временем это их преимущество размывается. Вспомните, как было с Java: сначала это была экзотика, а теперь одна из самых распространенных технологий разработки, найти специалистов по которой совсем нетрудно. Более того, чем активнее заказчик принимает участие в управлении проектом, тем меньше требуется специфической экспертизы. Как видите, все рассуждения носят совершенно общий характер и никак не коррелируют с особенностями SOA. Это больше похоже на “теологическую” дискуссию о пользе и вреде аутсорсинга.

PC Week: Насколько реально создание SOA-систем в условиях использования мультивендорных технологий, в том числе с применением внешних независимых ИТ-сервисов?

Я. М.: Мне как раз непонятно, какой смысл использовать SOA в рамках внутренней корпоративной системы да еще на платформе одного вендора. В таких случаях обычно есть развернутое и хорошо согласованное API, которое позволяет обойтись без всяких модных “заморочек”, вроде SOA. Взять, например, продукты компании Microsoft. Все они замечательно интегрируются друг с другом без SOA, хотя и у Microsoft есть свои интеграционные SOA-технологии.

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

PC Week: Какова ваша общая оценка востребованности SOA на российском ИТ-рынке со стороны заказчиков?

Я. М.: Востребованность SOA со стороны заказчиков пока невелика, интерес к ней только сейчас появляется, в то время как на Западе накоплен огромный опыт построения SOA-систем. Я говорю не о росте личной эрудиции ИТ-специалистов, а о реально осознанной потребности организаций в построении SOA.

Причина неширокой распространенности SOA у нас кроется в консерватизме ИТ-служб. Вот если бы бизнес-лидеры были более продвинуты в технологиях и их взаимоотношения с «айтишниками» строились с большей долей доверия, то у нас, конечно, было бы больше примеров построения SOA. Но по мере интеграции России в мировую экономику будет меньше заметна разница с Западом. Это хорошо видно в банковской сфере, прогрессу в которой способствует приход в нашу страну западного бизнеса. Удачные примеры построения SOA в России как раз широко представлены в “дочках” иностранных банков. Спрос на SOA все-таки есть, значит, будет и предложение. Думаю, уже не менее десятка интеграторов могут квалифицированно вести SOA-проекты, дальше, несомненно, их будет больше.

PC Week: Что еще в SOA-тематике кажется вам актуальным сегодня?

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