Service-Oriented Architecture (SOA) уже несколько лет подряд находится в центре внимания ИТ-сообщества. Но, несмотря на то что обсуждению SOA посвящены сотни мероприятий, дискуссий и статей, единого взгляда на ее определение и применение не возникает. В результате многие ИТ-специалисты так и остаются один на один со своими проблемами и вопросами. Мы пригласили к беседе о SOA специалистов, обладающих глубокими теоретическим познаниями и серьезным практическим опытом реализации проектов в области моделирования бизнес-процессов и интеграции приложений, чтобы дать если не ответы на вопросы, волнующие сегодня многих руководителей ИТ-структур, то, по крайней мере, информацию к размышлению. В беседе приняли участие:Василий Анфиногентов, руководитель отделения автоматизации деловых процессов компании «ФОРС — Центр разработки», Павел Болотин, руководитель отдела программных платформ компании «Открытые Технологии», Дмитрий Бредихин, ведущий инженер-программист «РБК СОФТ» (группа компаний «Армада»),  Игорь Городничев, директор направления портальных технологий и систем документооборота «РБК СОФТ» (группа компаний «Армада»),  Максим Галимов, директор по перспективным исследованиям DIRECTUM,  Ирина Малиновская, главный специалист дирекции ИТ-консалтинга компании СИБИНТЕК, член itSMF Россия, Андрей Сыкулев, директор по развитию бизнеса компании BSC.

–Давайте начнем беседу с определения SOA. Границы этого термина очерчены нечетко, поэтому возникают разночтения в толкованиях. Что вы понимаете под этим термином? В чем ее основная цель? Что относят к SOA ошибочно?

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

Д. Бредихин: SOA — это подход к реализации информационных инфраструктур, позволяющий создавать системы, которые не зависят от программных реализаций их компонент; системы, ставящие основной целью выделение и оформление в стандартизованном виде отдельных сущностей и бизнес-функций каждой конкретной подсистемы. Именно стандартизация интерфейсов к информационным системам и их бизнес-функциям посредством веб-сервисов позволяет перейти к следующему уровню абстракции при проектировании и реализации взаимодействия между информационными системами.

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

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

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

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

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

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

И. Малиновская: Понятие внедрения применяется обычно к каким-либо конкретным программным продуктам, аппаратным средствам или строго определенным технологиям. В общем случае аббревиатуру SOA следует ассоциировать с парадигмой — исходной концептуальной схемой, дополненной набором основных правил.

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

П. Болотин: В России под внедрением SOA пока нередко подразумевают лишь внедрение продуктов программной инфраструктуры SOA — сервисных шин, BPM-средств, порталов, мониторов бизнес-производительности и т. п.

А. Сыкулев: С технической точки зрения, SOA — это набор методов, стандартов, протоколов и инструментов разработки. Центральное место в сервисной архитектуре занимают две компоненты — сервисная шина предприятия (ESB), обеспечивающая взаимодействие сервисов, и репозиторий, через который осуществляется хранение сервисов и управление ими. Если мы говорим о ESB или о репозитории сервисов, то, скорее, применимо слово «внедрение», так как чаще всего здесь используются готовые продукты, которые есть у многих поставщиков инфраструктурного ПО. Применительно к самим сервисам, создаваемым с использованием подходов SOA, более правильно говорить о жизненном цикле, состоящем из последовательно повторяющихся четырех основных этапов: моделирование, сборка (или разработка), внедрение и эксплуатация.

И. Городничев: Словосочетание «внедрение SOA» связано с реальностью, в которой находится большинство крупных компаний: в результате продолжительной работы ИТ-подразделений создано множество информационных систем, от функционирования которых зависят производственные подразделения, непросто начать серьезную модернизацию. Мигрировать к новой архитектуре приходится постепенно, внедряя отдельные решения. Обычно внедрение SOA проходит следующим образом: разрабатывается центральный узел, на котором регистрируются все «совместимые» сервисы предприятия (это не только «веб-сервисы»: SOA-шины IBM, Oracle и других вендоров имеют коннекторы к базам данных, системам ERP и т. д.). Затем описывается та часть бизнес-процессов, которая реализуется данными сервисами. Начинать целесообразно с наиболее востребованных сервисов, которые задействованы в ключевых бизнес-процессах, как правило, объединяющих несколько подразделений и требующих их информационного взаимодействия. Прочие системы, не подключаемые к SOA-шине на первом этапе, продолжают работать до тех пор, пока не будут модернизированы или заменены по мере возникновения потребности в их использовании в бизнес-процессах организации, выходящих за рамки конкретного подразделения, создавшего систему.

— Как любая новая концепция или технология, SOA на начальном этапе существования объявлялась чуть ли не панацеей от всех проблем ИТ-департамента. Для каждой ли компании она подходит? Существуют ли компании (бизнесы), для которых данная концепция противопоказана? Что определяет степень ее применимости для предприятия?

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

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

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

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

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

И. Малиновская: Очевидно, что принятие сервисной парадигмы легче всего дается сервисным компаниям, которые имеют опыт предоставления услуг внешним потребителям и хорошо понимают специфику создания и описания услуг, а также управления их качеством. Копаниям, специализирующимся на аутсорсинге ИТ-услуг, давно известны правила составления SLA (service level agreement). Лучшая практика управления в сфере ИТ, описанная в новой, третьей версии ITIL, дает подход с точки зрения жизненного цикла услуги (service lifecycle), который, по мнению некоторых специалистов SOA, идеально применим при создании управления SOA (SOA governance).

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

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

Д. Бредихин: Для использования архитектуры SOA оптимально подходят компании, которые ясно представляют бизнес-функции своих подразделений. Очень хорошо, если ИТ-подразделения компании работают в соответствии с рекомендациями ITIL/ITSM. В таком случае SOA-решения органично вписываются в инфраструктуру. Если же компания, которая традиционно считает ИТ-подразделение «центром затрат», решит реализовать архитектуру SOA, то велика вероятность что на выходе будет получено мощное решение по интеграции различных информационных систем без какого-либо анализа бизнес-процессов, происходящих в компании (второй-третий уровень «зрелости» SOA). Является ли это неудачным внедрением? Решать заказчику, но важно понимать, что SOA не панацея от проблем в управлении.

— Кто является инициатором применения SOA в компании: CIO или CEO? Зачем SOA бизнесу и зачем — ИТ?

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

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

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

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

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

П. Болотин: Согласен, пока инициатор все-таки CIO. Для CEO термин SOA до сих пор воспринимается как модное течение в ИТ, игрушка, не более того. Увеличение количества внедрений и успешных бизнесов, использующих SOA в своих системах, поможет изменить ситуацию. Выгоды для бизнеса уже не раз озвучивались — гибкость, разноподчиненность, для ИТ — увеличение скорости внедрения новых сервисов, снижение рисков по изменению систем, повышение доверия к ним со стороны бизнеса.

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

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

— На каком этапе зрелости управленческих процессов и ИТ компании есть смысл принять парадигму SOA?

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

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

И. Малиновская: На мой взгляд, рассмотрение вопроса об использовании SOA на уровне стратегии бизнеса не может быть преждевременным, ибо с выбором модели управления разумно определиться как можно раньше. Подготовка SOA-инициатив на уровне создания ИТ должна проводиться на основе анализа модели бизнес-услуги. Поэтому не стоит заранее привязываться именно к процессам, ведь модель бизнес-услуги может строиться на основе не только процесса (process service), но и какой-либо сущности (entity-centric business service) или ожидаемого результата (task-centric business service). Внедрение отдельных средств SOA на уровне операционной деятельности не может заменить принятие SOA в масштабах организации.

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

— В чем может выражаться влияние SOA на изменения в организационной модели компании?

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

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

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

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

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

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

П. Болотин: Если специфика бизнеса предполагает разность процессов в территориально-распределенных офисах, то SOA здесь как нельзя кстати. Например, использование BPM-средств позволит выстроить необходимые процессы, а сервисный подход — выдержать гранулированность функциональных блоков. Замена модулей на местах — камень преткновения в подобных проектах — также может происходить постепенно. Некоторые функциональные блоки на переходных периодах могут быть взяты из унаследованных систем путем интеграции их при помощи адаптеров.

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

Д. Бредихин: Все зависит от «глубины погружения» сервис-ориентированной архитектуры в подразделения холдинга. Если строится единый корпоративный узел SOA, то в нем обычно реализуют только процессы «верхнего уровня», используя сервисы региональных подразделений в качестве источников и потребителей данных глобальных бизнес-процессов. Стандартизация сервисов обеспечивается или в техническом задании на разработку региональных модулей для интеграции с корпоративным узлом, или средствами продуктов, реализующих шину SOA (трансформация форматов данных и транспортных протоколов). Если же архитектура холдинга предполагает создание региональных SOA-узлов, то в ходе внедрения обязательно потребуется модификация типовых бизнес-процессов для каждого филиала. Эти задачи адаптации не идут вразрез с общей концепцией SOA, поскольку внешние сервисы подразделений, используемые на уровне всего холдинга, будут стандартизированы.

— Каковы особенности SOA для компаний с централизованной и децентрализованной ИТ-структурами?

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

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

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

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

П. Болотин: Позволю себе не согласиться. Идеология большинства вендоров — продавать свои товары вместе со своими, т. е. Best of Suite. Убедиться в этом можно будет с появлением SOA-версий ERP-систем от лидеров рынка. И если вдруг окажется, что программная инфраструктура SOA не совместима с внешними сервисами, то доверие к самой инфраструктуре может быть подорвано. Это значительно упростит борьбу с неугодными вендорами на этапе конкурсов. На мой взгляд, данное противоборство должно выступить самоорганизующим фактором. Все, что остается вендорам, — быть лучшими и в сервисах.

А. Сыкулев: Концепция SOA в ИТ далеко не первая, в которой фигурирует идея «универсальных кубиков». Во-первых, существенная разница, отличающая SOA от предыдущих попыток, заключается в том, что SOA основана на индустриальных стандартах, таких, как BPEL, XML, WSDL, SOAP etc., что потенциально (при желании заказчика) ставит вендоров прикладного ПО в равные условия. Во-вторых, правильная техническая реализация сервисной шины предприятия (ESB) позволяет убрать вендоро-специфические технологии из бизнес-значимых сервисов, составляющих бизнес-процессы, на более низкий уровень. В-третьих, на рынке уже известны случаи успешного взаимодействия прикладного ПО от разных вендоров.

— Известны ли вам примеры удачной реализации SOA в России? Что является критерием успеха? Может ли опыт одних компаний быть перенесен в практику других?

П. Болотин: Мне известно о нескольких внедрениях в кредитно-финансовой сфере — процессинг, кредитные системы, интеграция с российскими системами отчетности. Казахстанский телеком опера тор интегрировал системы CRM, Billing и OSS/BSS для сквозного управления процессами модели eTOM — operations. Успешность сегодня — доведение проекта до работоспособного состояния. Пока это энтузиазм, отдача будет позже, когда потребуется процессы менять. Что касается переносимости — посмотрим, как будут развиваться события. Рынок розничных услуг очень динамичный. И если что то есть у одного игрока, оно тут же появляется и у другого.

В. Анфиногентов: У ФОРС есть реальный опыт построения больших информационных систем на базе SOA. Недавно была запущена система автоматизированного предоставления государственных услуг населению «Одно окно», разработанная по заказу Управления информатизации Москвы. Продолжаются работы по созданию среды электронного взаимодействия городских ИС в рамках метасистемы «Электронная Москва», что обеспечит интеграцию и взаимодействие комплекса разнородных ведомственных и отраслевых информационных подсистем. В основе обоих проектов лежит SOA на базе Oracle Fusion Middleware.

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