Как добиться совершенства в SOA

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

Многие эксперты в области SOA пытались обозначить ключевые факторы успеха при реализации SOA-проекта. Приводим их в качестве теоретического фундамента:

• Не забывайте, что SOA – не проект, а парадигма. Нельзя «начать» и «закончить» внедрение SOA, так как «архитектура» – это не то, что внедряют. Это то, что разрабатывают, чем пользуются и что поддерживают.
   
• Правильно выделяйте сервисы. Излишняя «мелочность» при выделении ключевых сервисов – путь к трудностям в их интерпретации, а излишняя укрупненность – препятствие для повторного использования.
   
• Ведите единый каталог сервисов, актуальный на любой момент обращения к нему. Поддержание каталога сервисов в актуальном состоянии (идеально – онлайн-каталог, предоставляющий данные в режиме реального времени) – залог адекватности и идентичности знаний о сервисах у всех участников SOA-взаимодействий.
   
• Соотносите сервисы с бизнес-процессами. Эта рекомендация, относящаяся к правильному выделению сервисов, обращает внимание на то, что сервисы в SOA в конечном итоге создаются для бизнеса и должны быть спроектированы так, чтобы из них легко строились и перестраивались бизнес-процессы. Некоторые исследователи SOA даже вводят термин «процессного изоморфизма» (process isomorfism), достигаемого тогда, когда любой процесс в организации а) может быть выстроен как последовательность используемых сервисов и б)сам представляет собой сервис, который можно вызвать в ходе выполнения другого процесса. Эта рекомендация призывает архитекторов SOA соотносить свою работу с принципами управления бизнес-процессами (business process management, BPM).
   
• Управляйте изменениями. Любое изменение в архитектуре SOA должно пройти определенный цикл внедрения, включая анализ воздействия (impact analysis), согласование владельцами процесса и анализ реализуемости. Для выполнения этих функций можно использовать специализированное ПО для управления жизненным циклом сервисов, но, при наличии определенной дисциплины SOAв организации, может быть достаточно и обычной электронной почты.
   
• Управляйте мастер-данными. Master Data Management (MDM) – не менее важный фактор успеха SOA, так как цель построения сервис-ориентированной архитектуры – не только повышение уровня повторного использования разработанного функционала, но и увеличение гибкости ИТ-среды и ее готовности к изменениям, в том числе к подмене используемых ИТ-систем. При наличии большого количества ИТ-систем, содержащих в себе источники НСИ, следует управлять этими источниками так же четко, как и сервисами.
   
• Управляйте сервисами не только на бумаге. SOA должна существовать не только в виде реестров и прочих описаний, это должна быть полноценная технологическая платформа интеграции, дающая возможность реализовывать единый подход в неоднородной инфраструктуре.

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

SAS (Scandinavian Airlines), Дания/Норвегия/Швеция

Один из крупнейших авиаперевозчиков скандинавского региона, компания SAS представляет собой яркий пример по-настоящему распределенной корпорации – под началом SAS состоят 4 независимых, по сути, авиакомпании. Даже единой штаб-квартиры у SAS нет – действуют 3 штаб-квартиры в Швеции, Норвегии и Дании. Естественно, что такой стиль ведения бизнеса изначально потребовал от компании четкой управленческой дисциплины – как в бизнесе, так и в области ИТ.

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

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

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

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

Что дал SAS проект по переходу на единую платформу управления SOA? Сама компания отмечает следующие преимущества:

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

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

SaskTel, Канада

Для многих жителей России, да и всего постсоветского пространства, Канада выглядит своеобразным «белым пятном». Мы мало знаем о том, как живут люди в этой стране, какой в канадских компаниях уровень развития ИТ и, в частности, уровень развития SOA. Смею вас заверить – жизнь (и ИТ-жизнь) в Канаде есть, и все инновационные решения там принимаются на вооружение с не меньшей интенсивностью, чем в старушке-Европе. Один из таких примеров – канадская телекоммуникационная компания SaskTel.

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

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

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

Идеальное решение для этих задач – комплекс программных средств, позволяющий реализовать все запрошенные средства сразу. Таким комплексным продуктом стал пакет webMethods от Software AG: он содержит и интеграционную платформу (шину ESB), и BPMS (функциональность для управления бизнес-процессами), и репозиторий web-сервисов (тот же продукт CentraSite, который работает в SAS). Кроме того, так как Software AG – долгожитель ИТ-рынка, в ее багаже нашлись и модули для интеграции с мейнфреймами.

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

• экономия от 400 до 800 тысяч долларов в год на запуске каждого нового большого продукта – за счет разработки  приложений, ориентированных на клиентов компании;
   
• до $1 млн в год на стоимости рабочей силы  – за счет улучшения качества автоматизации и сокращения операционных издержек;
   
• многократное уменьшение трудозатрат на проектах по внедрению нового функционала: то, на что раньше требовалось 2000 человеко-дней, теперь укладывается в 200.

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

Так что, как это ни банально звучит, чтобы добиться совершенства в SOA, нужно перейти от ожидания этого совершенства (ожидания чуда от внедрения SOA-продукта фирмы A или проведения SOA-консалтинга фирмой B) к упорному труду по его достижению. Тогда, как в случае с компаниями SAS и SaskTel, будет и реальная отдача от SOA.