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

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

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

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

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

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

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

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

М. С.: Самое сложное в SOA-проекте — согласовать интересы различных команд — как разработчиков, так и заказчиков. Рекомендуемый Gartner Group принцип городского планирования (City Planning Principle) используется современными компаниями при построении ИТ-инфраструктуры и организационном выделении ИТ-отдела. С прикладным ПО ситуация иная. Обычно с каждым самостоятельным бизнес-подразделением работает выделенная ИТ-команда, воспринимающая требования заказчика как безусловное руководство к действию. В такой ситуации не просто убедить как одних, так и других, что сервисы — это общий ресурс, не принадлежащий какому-то одному бизнес-домену. Большим подспорьем в этой ситуации является центр компетенций SOA, берущий на себя согласование архитектурных договоренностей и зачастую призванный пересмотреть сложившиеся, но неэффективные связи между пользователями и ИТ-шниками.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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