 |
|
|
|
SOA: плюсы и минусы. Готовы ли компании к SOA-архитектуре?
SOA: плюсы и минусы Аналитическое агентство CNews Analytics /CNA/ исследовало настроения участников рынка. Оказалось, что интерес к SOA остается высоким. Многие компании корректируют свои SOA-стратегии, чтобы подготовить ИТ-инфрастуктуру и бизнес к быстрому выходу из кризиса. Что нужно учитывать? SOA – это долгосрочный трансформационный проект. Могут пройти годы – перед тем как бизнес почувствует реальные результаты (например, возможность быстрой адаптации ИТ под новые процессы).
Рисунок 1. Готов ли российский рынок к массовым SOA-проектам? (Источник: CNews Analytics, 2009)
Рисунок 2. Будут ли компании выделять средства на SOA в кризис? (Источник: CNews Analytics, 2009) CIO, разработчики и бизнес-пользователи видят SOA (и его эффективность) по-разному. Преимущества SOA:
Особенности SOA:
Однако
Сложности на пути SOA Организационные – заинтересованность руководства, мотивация сотрудников. Экономические – большие начальные инвестиции. Ресурсные – дефицит кадров, неготовность инфраструктуры. Технические – трудоемкость проектов, большой объем подготовительных работ. Психологические – консервативность, излишние амбиции на старте, быстрое разочарование. Стоимость перехода SOA-проект требует значительных инвестиций сразу по нескольким направлениям: Создание сервисов: создание повторно используемого компонента примерно в два с половиной раза дороже простого. Это значит, что сервис создается при условии дальнейшего использования (минимум трижды). Софт: ESB (самая затратная часть), репозиторий, системы тестирования, управления и мониторинга. Железо: возможно потребуется дополнительно оборудование (не самая большая статья расходов). Обучение ИТ-персонала работе с SOA. Какова отдача? IBM SOA Infrastructure Adoption Study провела опрос 900 ИТ-директоров и топ-менеджеров компаний из Северной Америки, Европы и Азии:
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 |
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
