Как добиться совершенства в SOA
История сервисно-ориентированного подхода насчитывает достаточное число как удачных примеров его внедрения, так и откровенно слабых проектов, не принесших заказчикам и исполнителям ничего, кроме разочарования. В результате складывается довольно интересная картина: позитивное отношение к самому подходу (за исключением случаев, когда ожидания от внедрения SOA были явно завышены) сочетается с негативной реакцией на предложение провести проект по внедрению SOA(мол, все само как-нибудь образуется). По-видимому, IT-индустрии до сих пор не хватает ярких историй успеха и «путеводных звезд», на которые энтузиасты 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, так как построение сервисно-ориентированной архитектуры имеет целью не только повышение уровня повторного использования разработанного функционала, но и увеличение гибкости IT-среды и ее готовности к изменениям, в том числе к подмене используемых IT-систем. При наличии большого количества IT-систем, содержащих в себе источники НСИ, следует управлять этими источниками так же четко, как и сервисами.
- Управляйте сервисами не только на бумаге. SOA должна существовать не только в виде реестров и прочих описаний, это должна быть полноценная технологическая платформа интеграции, дающая возможность реализовывать единый подход в неоднородной инфраструктуре.
Казалось бы, уже все IT-архитекторы знают эти простые правила, однако по-прежнему некоторые внедрения SOA удачны, а некоторые – нет. В противовес первым, где истинные причины проблем, как правило, замалчиваются, об удачных проектах зачастую громко говорят, так что на их примере можно попытаться выработать оптимальный путь реализации SOA «под себя». Практический блок этой статьи как раз и содержит примеры успешного внедрения SOA конкретными компаниями.
SAS (Scandinavian Airlines), Дания/Норвегия/Швеция
Один из крупнейших авиаперевозчиков скандинавского региона, компания SAS являет собой яркий пример по-настоящему распределенной корпорации – под ее началом состоят четыре независимые по сути авиакомпании. Даже единой штаб-квартиры у SAS нет – действуют штаб-квартиры в Швеции, Норвегии и Дании. Естественно, что такой стиль ведения бизнеса изначально потребовал четкой управленческой дисциплины – как в бизнесе, так и в области ИТ.
SAS руководствуется принципами SOA при управлении IT-ландшафтом уже более пяти лет, но по мере своего роста компания начала замечать недочеты в реализации некоторых ключевых аспектов SOA. Во-первых, остро обозначилась необходимость правильного документирования сервисов и упрощения их использования в дальнейшем. Во-вторых, чувствовалась потребность в проведении анализа воздействия – в целях осуществления контролируемых изменений в гетерогенной и географически разнесенной IT-среде. Кроме того, компания ждала от нового витка развития SOA избавления от некоторых застарелых проблем:
- разработки одинаковых или пересекающихся по функциональности сервисов в различных проектах;
- разрешения трудностей в анализе взаимоотношений сервисов и определении корневых причин возникающих сбоев;
- сокращения числа неконтролируемых web-сервисов в разных подразделениях и от разных поставщиков;
- вовлечения сервисов, разработанных для внутреннего использования, в проекты по обслуживанию потребителей вне компании.
Итогом анализа потребностей стала осознанная необходимость перехода на использование единого организационно-технического решения по управлению SOA- средой (SOA Governance), включающей в себя: реестр/репозиторий сервисов; функциональность для анализа взаимоотношений, воздействий и определения корневых причин сбоев; возможность централизованного управления жизненным циклом сервисов – от проектирования и разработки до модификации и вывода из эксплуатации.
Помимо сугубо организационных мер, предписывающих всем сотрудникам определенный подход к управлению IT-средой, ситуация требовала выбора и внедрения программного решения, отвечающего потребностям SAS как по функциональности, так и по масштабу. Таким решением стал репозиторий CentraSite от немецкого поставщика ПО Software AG, сочетающий в себе все запрошенные SAS функции с возможностями масштабирования под любой размер и территориальную распределенность предприятия.
Что дал SAS проект по переходу на единую платформу управления SOA? Сама компания отмечает следующие преимущества:
- более эффективное управление SOA в масштабе всего предприятия;
- новый уровень анализа взаимоотношений и взаимодействий;
- повышение гибкости бизнеса и гибкости при реагировании на изменения требований регулирующих органов;
- вовлечение существующих IT-систем в процесс поддержки единой бизнес-стратегии;
- сокращение сроков вывода сервисов в продуктивную эксплуатацию и улучшение управления SOA-артефактами;
- сокращение времени на устранение сбоев и уменьшение степени их влияния на бизнес.
Отметим, что в этом случае речь идет о компании, уже имевшей достаточно высокий уровень зрелости по SOA. Для достижения «совершенства» не хватало связующего звена, которым и стал репозиторий CentraSite. Но есть и другие компании, где построение SOA приходится начинать с «фундамента», с закладки основ.
SaskTel
SaskTel – крупный телекоммуникационный оператор Канады. Эта компания предоставляет на рынке Канады широкий спектр продуктов и услуг: беспроводной доступ в Интернет, IPTV, высокоскоростные линии и многое другое. Компания эволюционно развивалась: росло количество подразделений, а с ним и численность персонала, ширился спектр предлагаемых компанией продуктов и услуг. Параллельно усложнялась корпоративная IT-инфраструктура.
Изначально компания не придавала особого значения грамотному управлению ИТ, и новый функционал внедрялся по принципу «нужно вывести на рынок новый продукт – напишем или внедрим еще одну ИС для его поддержки». Несложно вообразить, что представлял собой IT-ландшафт SaskTel к моменту, когда в ней работало более 5 тыс. человек и перечень предлагаемых на рынке телеком-продуктов исчислялся десятками. Устаревшие технологии, неподдерживаемый код и высокие риски отказа пудовой гирей висели на ногах IT-подразделений. Бизнес-руководство компании, в свою очередь, было сильно недовольно как непомерными расходами на поддержку ИТ, так и слишком длительными сроками реализации новых и модернизации имеющихся функциональных возможностей. Все это подталкивало к принятию радикальных мер в отношении ИТ, одной из них и стало решение о реализации в SaskTel сервисно-ориентированного подхода в управлении IT-инфраструктурой. Более конкретно задачи выглядели так:
- выполнить интеграцию приложений на базе единой сервисной шины (ESB), позволяющей вести централизованный и единообразный контроль за всем информационным обменом между приложениями;
- реализовать функциональность по управлению сквозными бизнес-процессами, включая их быструю разработку, «обвязку» пользовательскими интерфейсами, внедрение и последующий мониторинг с позиций бизнеса;
- организовать реестр/репозиторий сервисов, позволяющий быстро находить уже разработанный функционал и грамотно использовать его при построении новых приложений;
- интегрировать наработанный «до SOA» функционал, в том числе развернутый на мейнфреймах, и обеспечить в дальнейшем возможность легкой подмены этого функционала новыми системами.
Правильно решение для этих задач – использование комплекса программных средств, позволяющий реализовать все запрошенные средства сразу. Таким комплексным продуктом стал пакет webMethods от Software AG: он содержит и интеграционную платформу (шину ESB), и BPMS (функциональность для управления бизнес-процессами), и репозиторий web-сервисов (CentraSite). Кроме того, так как Software AG долгожитель IT-рынка, в ее багаже нашлись и модули для интеграции с мейнфреймами.
Выбор единой SOA-платформы позволил SaskTel убить сразу целое стадо зайцев. Как говорят сами IT-менеджеры SaskTel: «SOA-платформа дала нам возможность создавать вещи, о которых мы раньше не могли и подумать». Компания не побоялась озвучить и цифры:
· экономия от 400 до 800 тыс. долларов в год на запуске каждого нового большого продукта (за счет разработки приложений, ориентированных на клиентов) и до $1 млн в год – на стоимости рабочей силы (за счет повышения качества автоматизации и сокращения операционных издержек);
· уменьшение трудозатрат на проектах по внедрению нового функционала: то, на что раньше требовалось 2000 человеко-дней, теперь укладывается в 200.
Конечно, компании с меньшими оборотами и меньшим числом сотрудников и приложений вряд ли смогут продемонстрировать столь же значительные результаты. Впрочем, далеко не каждой компании требуются такие масштабные IT-проекты. Вообще, ПО для SOA – отнюдь не единственный (и иногда даже не решающий) компонент лекарства, излечивающего детские болезни корпоративных ИТ. Дело в том, что внедрение SOA вряд ли может стать проектом в классическом смысле этого слова, с четко ограниченными сроками и результатами, которые устраивают всех и навсегда. Для того чтобы начать приносить пользу, сервисно-ориентированный подход и выстраивание соответствующей архитектуры должны стать «нормой жизни» – как для IT-подразделения, так и для постановщиков задач для него. И уже в рамках этой SOA-нормы могут реализовываться этапы по расширению области действия, добавлению новых возможностей и вовлечению новых участников.
Так что, как ни банально это звучит, чтобы добиться совершенства в SOA, нужно перейти от ожидания этого совершенства (ожидания чуда от внедрения SOA-продукта фирмы “A” или проведения SOA-консалтинга фирмой “B”) к упорному труду по его достижению. Тогда, как в случае с компаниями SAS и SaskTel, будет и реальная отдача от SOA.
Источник: IT News №17 (октябрь 2011 года)
Опубликовано 11.10.2011