SOA: плюсы и минусы. Готовы ли компании к SOA-архитектуре?::Журнал СА 102009

SOA: плюсы и минусы
Готовы ли компании к SOA-архитектуре?

Аналитическое агентство CNews Analytics /CNA/ исследовало настроения участников рынка. Оказалось, что интерес к SOA остается высоким. Многие компании корректируют свои SOA-стратегии, чтобы подготовить ИТ-инфрастуктуру и бизнес к быстрому выходу из кризиса.

Что нужно учитывать?

SOA – это долгосрочный трансформационный проект. Могут пройти годы – перед тем как бизнес почувствует реальные результаты (например, возможность быстрой адаптации ИТ под новые процессы).

Рисунок 1. Готов ли российский рынок к массовым SOA-проектам? (Источник: CNews Analytics, 2009)

Рисунок 2. Будут ли компании выделять средства на SOA в кризис? (Источник: CNews Analytics, 2009)

CIO, разработчики и бизнес-пользователи видят SOA (и его эффективность) по-разному.

Преимущества SOA:

способность быстро адаптировать ИТ к меняющимся задачам бизнеса;
стимул для анализа и оптимизации бизнес-процессов компании;
возможность обеспечить интеграцию при консолидации компаний (= систем);
возможность снизить ТСО систем.

Особенности SOA:

продолжительные сложные проекты;
переосмысление ИТ-стратегии предприятия в целом.

Однако

проект SOA должен решать задачи не ИТ-департамента, а бизнеса в целом;
часто результат SOA – красивая инфраструктура, но не реальная ценность для бизнеса.

Сложности на пути SOA

Организационные – заинтересованность руководства, мотивация сотрудников.

Экономические – большие начальные инвестиции.

Ресурсные – дефицит кадров, неготовность инфраструктуры.

Технические – трудоемкость проектов, большой объем подготовительных работ.

Психологические – консервативность, излишние амбиции на старте, быстрое разочарование.

Стоимость перехода

SOA-проект требует значительных инвестиций сразу по нескольким направлениям:

Создание сервисов: создание повторно используемого компонента примерно в два с половиной раза дороже простого. Это значит, что сервис создается при условии дальнейшего использования (минимум трижды).

Софт: ESB (самая затратная часть), репозиторий, системы тестирования, управления и мониторинга.

Железо: возможно потребуется дополнительно оборудование (не самая большая статья расходов).

Обучение ИТ-персонала работе с SOA.

Какова отдача?

IBM SOA Infrastructure Adoption Study провела опрос 900 ИТ-директоров и топ-менеджеров компаний из Северной Америки, Европы и Азии:

50% игроков, реализующих SOA-проекты, констатируют возврат инвестиций;
более 60% из тех, кто ставил задачу сокращения издержек, отмечают достижение этой цели.

Infosys: После перехода на СОА с каждым годом возрастает количество повторных использований сервисов (+10-15% в первый год, +20-25% во второй год, +30-40% на третий год и т.д.) – что напрямую сказывается на сокращении затрат.

Что можно измерить переходя на SOA?

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

Старт SOA-проекта

Ваша компания готова к старту SOA-проекта, если у нее есть:

Инфраструктура – достаточная пропускная способность сети, доступность серверов.

Архитектура – приложения позволяют выставлять данные в качестве сервисов.

Информация – готовность данных к представлению в виде сервисов, адекватная структура хранилища.

Человеческие ресурсы – уровень квалификации, знакомство с технологиями, адаптивность, готовность к работе в новых парадигмах.

Управление – заинтересованность топ-менеджмента, инновационный настрой, инициативность CIO.

Шесть ошибок в SOA -проектах

Беспорядочный подход к сервисам. Начиная проект, компании часто бездумно выделяют веб-сервисы; среди них оказываются избыточные или ненужные, а процедура становится неоправданно дорогой.

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

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

Приоритет большим и сложным проектам. Лучше начать с небольших и минимально рисковых проектов (менее очевиден результат, но зато хорошая площадка для обучения, накопления опыта и необходимой базы знаний). У сложных и крупных инициатив риски очень высоки, они чаще проваливаются.

Непонимание ключевых ролей. Бизнес-роли должны быть заложены еще на стадии планирования. Часто у проектной команды и ее руководителя нет четкого понимания – кто является ключевым «владельцем» данных. Проект, в котором нет изначального понимания, какие подразделения владеют какими сервисами, обречен.

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

Приложение

Стереотипы поведения уничтожают преимущества

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

Максим Смирнов,

руководитель департамента архитектуры
систем поддержки бизнеса ОАО «ВымпелКом»

Поддержка SOA-решений сложнее привычных соединений

Трудности возникают по нескольким направлениям. Это трудности технологические (некоторые решения в стиле SOA построить с соблюдением заявленных атрибутов качества крайне сложно); ресурсные (пока SOA является только архитектурной парадигмой, используемой при построении решений, но не выделена в проект, достаточно приоритетный для банка, недостаточно ресурсов для процессов стандартизации, определения бизнес-объектов и т.д., объединяемых словом governance).

Некоторые трудности возникают, конечно, в связи с тем, что решения в стиле SOA на этапе накопления сервисов являются более сложными и затратными, чем при peer-to-peer-интеграции. Это трудности как на уровне менеджеров проектов, которым приходится разъяснять, почему в проект добавлен «архитектурный налог» в виде создания сервисов, так и на уровне, например, системных администраторов, для которых поддержка SOA-решений объективно сложнее привычных peer-to-peer-соединений.

Эдуард Петренко,

главный эксперт департамента ИТ,
управление архитектуры и системных центров компетенции
ЗАО «ЮниКредит Банк»

Трудности есть, но они преодолимы

В 2006 году, при построении SOA в банке Ренессанс Капитал (Ренессанс Кредит), где в то время я занимал должность главного архитектора ИТ, мы сталкивались со следующими трудностями. Во-первых, сложно было убедить бизнес в необходимости трансформации в соответствии с подходом SOA. Но пока бизнес не поймет преимуществ SOA и не станет деятельно сотрудничать с ИТ, построение SOA невозможно. Стратегическую цель перехода к SOA определил тогдашний Chief Operating Officer Вольфганг Хайнрих. Однако основную роль пропагандиста SOA-подхода к построению ИТ-архитектуры в банке взял на себя Ярослав Медокс, бывший директором департамента развития ИТ. Благодаря их деятельности стал возможен постепенный переход к SOA-архитектуре в банке. Вторая проблема – кадры. Для построения SOA требуются квалифицированные сотрудники. Сначала мы привлекли специалистов компании «Неофлекс». Постепенно экспертиза появлялась и у сотрудников банка. В-третьих, закономерны технические сложности. Для нас они состояли в том, продуктовая линейка IBM WebSphere ESB V6 и IBM WebSphere Process Server V6 была еще довольно «сырой». Однако нам удалось впервые в России построить кластер WebSphere ESB и WebSphere Process Server, в так называемой, золотой топологии.

Алексей Букавнев,

IBM Certified SOA Solution Designer