Участники круглого стола:
- Фарид Сулейманов, заместитель главного системного архитектора, Альфа-банк
- Дмитрий Грязнов, директор департамента программной интеграции, «Ай-Теко»
- Ярослав Медокс, директор департамента развития информационных систем, банк «Ренессанс-Кредит»
- Константин Жуков, консультант по SAP NetWeaver компании SAP AG
- Владислав Боркус, директор по ИТ-консалтингу и исследовательским проектам, агенство Konassi.
Ведущие круглого стола: Константин Зимин, Ольга Мельник
Intelligent Enterprise: Давайте для начала определимся с понятиями. Существует довольно много различных определений SOA — сервисно-ориентированной архитектуры. Какое из них вы считаете наиболее корректным?
Ярослав Медокс: Для себя мы выбрали то, которое дается в книге IBM (Компас в мире сервис-ориентированной архитектуры): SOA — это каркас для интеграции бизнес-процессов и поддерживающей их ИТ-архитектуры в форме безопасных и стандартизированных компонентов: служб, которые можно использовать многократно и комбинировать для адаптации к изменяемым приоритетам бизнеса. Последние слова — «адаптация к измененяемым приоритетам» — являются здесь ключевыми. Это определение мы используем внутри ИТ-службы «Ренессанс-Кредита». Если у кого-то из сотрудников возникают вопросы или сомнения, мы адресуем их к нашему внутреннему описанию этого подхода, включающему и данное определение.
Владислав Боркус: На мой взгляд, определение заключено в самом названии SOA. С моей точки зрения SOA — это в первую очередь архитектура построения ИТ-системы на предприятии, призванная повысить скорость реакции ИТ на запросы бизнеса и основанная на идее выделения сервисов. То есть набор технических подходов к построению ИТ-инфраструктуры плюс набор организационных методов, необходимых для того, чтобы выполнить техническую часть. По сути это набор идей и методологий, для реализации которых возник целый класс ПО. Все вендоры сходятся в том, что должны быть сервисы и должны быть инструменты, позволяющие организовать эти сервисы в нечто повторно используемое. Первые идеи такого рода появились в начале девяностых годов для технологии CORBA. Именно на ней, а также на базе систем управления очередями сообщений вначале создавались решения SOA, например, в Credit Suisse и других финансовых организациях. Появление веб-сервисных стандартов реанимировало интерес к этой архитектуре. С возникновением веб-сервисов строить такие решения стало проще, поскольку вендоры договорились о технологической стороне дела, «разброд и шатания» прекратились и возник мощный маркетинговый импульс. На этом фоне и возродился интерес к идеям, высказанным более десяти лет назад, которые за прошедшее время обросли методиками реализации.
Константин Жуков: SAP предлагает свое определение и видение SOA: это корпоративная сервисно-ориентированная архитектура — Enterprise SOA. Она предоставляет бизнес-пользователям определенный уровень абстракции за счет использования корпоративных сервисов взамен значительно более детализированных Web-сервисов. Например, бизнес-пользователь может взаимодействовать с процессом высокого уровня «Выполнить проверку динамической доступности» вместо того, чтобы иметь дело со всеми детализированными сервисами, из которых состоит упомянутый выше высокоуровневый сервис (такими, как «Получите значения складских запасов», «Получите запланированные размеры заказа» и т. д.). Enterprise SOA предлагает новый способ определения бизнес-процессов, ориентированный скорее на бизнес, чем на ИТ. Иначе говоря, это SОА плюс бизнес-содержание, а ещё точнее — реализация SОА на ERP-уровне.
Фарид Сулейманов: Мы можем рассматривать понятие SOA c разных точек зрения, и определение будет зависеть как от нашей позиции (ИТ или бизнес), так и от наших целей.
Международная группа OASIS определяет SOA как общий подход к организации любой системы и бизнеса. Ключевыми моментами при этом являются сервисы и процессы, использующие их для достижения реальных целей. На мой взгляд, такой подход отражает в первую очередь современные требования бизнеса. Бизнес непрерывно совершенствуется, становится процессно-ориентированным, отсюда возникает требование к гибкости, которое проецируется на ИТ-системы.
Для нас как для банка с очень большой корпоративной информационной системой и ИТ-инфраструктурой существенна проблема монолитности составляющих ее приложений и систем. Монолитные приложения имеют различные платформы, стандарты разработки и сопровождения, что создает немало проблемы для ИТ-отдела — это высокие риски сопровождения, сложность общей интеграции и модернизации систем, необходимость выполнения больших объемов тестирования и т. д.
Кроме того, монолитные приложения реализуют наборы «сильно связанных» бизнес-функций, а бизнесу для автоматизации своих процессов все чаще бывают нужны отдельные функции из разных приложений. Возникает проблема гибкости: бизнес должен строить общий (сквозной) процесс, а все ИТ-решения традиционно сводятся к разработке, доработке или приобретению отдельных приложений, что ограничивает для него возможность быстро развиваться.
Таким образом, перед нами стоит задача перехода к сервисно-ориентированной архитектуре, в которой изменения в различных функциональных компонентах можно будет внедрять достаточно быстро и в максимальной степени независимо друг от друга, обеспечивая при этом непрерывное функционирование и мониторинг реальных бизнес-процессов, а также снижение общих издержек и рисков по внедрению и сопровождению систем.
В целом SOA можно понимать по-разному, но в любом случае это способ повышать и улучшать результаты своего бизнеса.
Дмитрий Грязнов: На мой взгляд это всё определения семилетней давности. Они устарели. Тогда еще не возникал вопрос о сервисном походе к управлению бизнесом. Говоря о SOA как интеграционной платформе, мы затрагиваем лишь технологическую часть. Мне кажется, SOA — это методика, позволяющая перевести ресурсы ИТ-подразделения в сервисы, которые используются бизнесом при процессном управлении. Это не набор модулей и не правила разбиения монолитных приложений на композитные, а именно методология: как из ресурсов ИТ сделать понятную бизнесу структуру.
Причем SOA — это трехкомпонентная модель, где на нижнем уровне находится интеграционная платформа, Enterprise Service Bus или иные подобные шины,, обеспечивающие единый источник данных для формирования сервисов. На этом уровне сервис является исполнителем повторяющихся бизнес-задач, которые вместе и составляют процесс. Второй уровень — каталог сервисов, оркестровка, поддерживающая систему. Здесь сервис — уже понятная бизнесу услуга. Она тарифицируема, измеряема, можно даже биллинговать ее. И третий уровень — управление бизнес-процессами. Идея SOA возникла в силу того, что в бизнес внедряются процессные методики, в результате которых бизнес рассматривается не как набор функциональных подразделений, а как набор процессов. Но тогда нужно понимать, а какие услуги в каждом элементе бизнеса используются. Поэтому на третьем уровне сервис — это управление бизнес-процессами.
Какая при этом будет архитектура: идти ли на связанные композитные приложения или обращаться к унаследованным системам раздельно, — значения не имеет. Будете ли вы использовать в каких-то элементах жесткое приложение — тоже неважно. Самое главное, что внедряя SOA мы трансформируем ресурсы ИТ-подразделения в услуги и управляем этими услугами.
Переход к SOA является более сложной задачей, чем это может показаться
Екатерина Волощенко, директор департамента электронного бизнеса и заказных разработок компании TopS BI (ГК «Систематика)
Сервисно-ориентированная архитектура — это модель создания корпоративных приложений, основанная на идее их компоновки из функциональных модулей, называемых сервисами. В SOA нужная функциональность собирается из сетевых сервисов, являющихся слабосвязанными и общедоступными. Модульные сервисы связываются с помощью четко определенных интерфейсов, не зависящих от конкретной реализации. Важной характеристикой такой архитектуры является возможность многократного использования сервисов при построении сложных составных решений, в которых консолидируются информация и функциональность успешно эксплуатируемых в компании автоматизированных систем. Преимущество слабосвязанных систем заключается в быстроте их действия и способности выдерживать кардинальные изменения как в структуре, так и в реализации любого сервиса.
Команда SOA-проекта обычно включает в себя, во-первых, группу, занимающуюся SOA-архитектурой. Эта группа анализиирует предметные области и технологии процессов, определяет круг необходимых бизнес-компонентов, сервисов и модулей процессов. Вторая группа отвечает за техническую сторону внедрения SOA. Ее основная задача — обеспечить слияние бизнеса с ИТ путём исполнения промышленных и корпоративных стандартов. Третья, группа разработки приложений, разрабатывает компоненты и модели бизнес-процессов, тестирует системы. И, наконец, четвертая группа — управления и эксплуатации — отвечает за развертывание сервисов, за обеспечение их поддержки, решает вопросы управления их компонентами и управления системой в целом.
В управлении проектом очень важно, чтобы, с одной стороны, разработчики архитектуры находились в тесном контакте со всеми проектными группами, а с другой — ответственная за создание архитектуры группа выполняла по отношению к группе разработки приложений роль скорее наставническую, а контролирующая роль была возложена на группу управления. Тогда разработчики приложений могут оценить значимость управления и осознать, что следование его политикам помогает им работать с меньшим напряжением и большим эффектом.
Основная проблема при создании слабосвязанной ИТ-инфраструктуры заключается в том, что имеющиеся приложения, как правило, сильно связаны между собой, и, таким образом, переход к SOA является более сложной задачей, чем это может показаться на первый взгляд. Такие проекты требуют значительных затрат и решимости «идти до конца».
Серьезную проблему составляет также нехватка квалифицированных кадров. Дело в том, что хотя SOA и предоставляет серьезные преимущества, она не создает хорошую архитектуру автоматически. А архитекторов, обладающих необходимыми навыками, не хватает. Ведь для того, чтобы быть настоящим специалистом по SOA, нужно хорошо владеть не только корпоративной, технической и информационной архитектурой, но также архитектурой бизнес-процессов и данных. Профессионалы подобного уровня пока еще встречаются не часто.
Intelligent Enterprise: Можно ли выделить те бизнесы или ситуации в бизнесе, когда SOA не нужна? И наоборот, когда необходима?
Ярослав Медокс: В компаниях со стабильным бизнесом SOA не нужна, а вот в высококонкурентной среде думать о ней однозначно стоит. Например, мы развернули ESB на базе продукта WebSphere ESB специально для одного проекта, а если бы не сделали этого, то потеряли бы контракт с одним из партнеров. Напротив, есть примеры, когда банки, лидирующие в каком-то виде услуг, отказываются от модернизации своих ИТ-структур, в том числе от перехода к SOA. И мой прогноз таков: в ближайшее время они потеряют заметную долю рынка.
Фарид Сулейманов: На мой взгляд, в границах одного предприятия можно выделить такие области, где она нужна, и такие, где этот подход не дает очевидного эффекта. Необходимо учитывать бизнес-факторы и ИТ-факторы. Бизнес-факторы — это стремление изменяться, выстраивать и перестраивать процессы, увеличивая при этом объемы операций и услуг. А ИТ-факторы — это необходимость не только эффективно решать конкретные бизнес-задачи, но и обеспечивать доступность, масштабируемость и управляемость всей информационной системы, в том числе с применением SOA. Граница применения SOA в большей степени определяется масштабом конкретного бизнеса, так как её внедрение требует высоких начальных инвестиций, а также хорошо организованного и технологически развитого ИТ-подразделения.
Дмитрий Грязнов: Добавлю, что использование этой архитектуры показано только в тех случаях, когда бизнес понимает, как работают ИТ, что они дают. Если нет задачи повышения конкурентоспособности или бизнес не видит одним из способов её повышения увеличение эффективности ИТ, то SOA не нужна.
Intelligent Enterprise: Реализацию SOA очень часто связывают с движением бизнеса (или готовностью двигаться) в сторону процессов и бизнес-компонентов. Причем успех SOA-проектов зависит именно от зрелости бизнеса в этой области. Насколько с вашей точки зрения оправданно такое представление? И кто должен первым продвигать процессные идеи — ИТ или бизнес?
Ярослав Медокс: На мой взгляд, те проекты, связанные процессным взглядом на бизнес, которые инициированы сверху в попытке повторить где-то виденный успех, проваливаются, а интерес к ним со стороны бизнеса теряется. Во всяком случае от банков я ни разу не слышал: «Мы здесь у себя внедрили процессный подход», — хотя ЦБ его и насаждает. Обычно процессный подход начинают внедрять в рамках функциональных подразделений и только потом пытаются сделать общую для предприятия модель процессов.
Я считаю, лучше, если генератором идей является ИТ-подразделение. Дело в том, что сейчас идет мощная конвергенция ИТ и управления бизнес-процессами, которые обязательно нужно анализировать при разработке сервисов. Наша задача — вывести продукт на рынок. Чтобы это сделать и поддержать новый продукт, нужно провести какие-то изменения в организации и ИТ. Значит, нужно этот процесс расписать поэтапно вплоть до деталей служебной инструкции для каждого сотрудника. И где-то в рамках этого проектного подхода и возникает описание бизнес-процессов, которое должно быть привязано к системам. Вот в этот момент SOA гарантированно дает нам какую-то пользу. Например, сервис «Открыть счет» мы использовали уже трижды.
При дальнейшем увеличении числа сервисов эти процессы обязательно сольются вместе, давая тем самым цельный процессный взгляд на бизнес. Поэтому, я думаю, в технологических компаниях функции управления бизнес-процессами должны быть внутри ИТ. Например, в моем подразделении есть отдел бизнес-анализа, однако пока пока мы не в состоянии обслуживать весь банк и директора по BPM у нас нет. Но если SOA-проект развивается без инициативы со стороны ИТ-отдела — на SOA сразу можно ставить крест.
Владислав Боркус: Трудно ожидать от ИТ-департамента, чтобы исключительно он занимался разработкой процессов, по которым функционирует организация.
Дмитрий Грязнов: Я не знаю ни одного заказчика, где это делал бы не ИТ-департамент. Однако в роли заказчика и инициатора движения часто выступают бизнес-подразделения.
Фарид Сулейманов: Отдельные бизнес-подразделения, как правило, стремятся строить свои процессы изолированно, т. е. разрабатывать свои частные решения, используя свои ресурсы и прикладные системы. Только ИТ-отдел может привести разные бизнес-направления к одному «знаменателю», определив общие технологические компоненты. Только он может сказать: «Коллеги, вы все хотите делать одно и то же, так давайте создадим такой сервис, которым все могли бы пользоваться». При этом расходы на создание сервиса могут быть распределены на всех его потребителей, что является сильным аргументом для бизнес-руководителей. Поскольку подразделения ИТ фактически являются держателями общих ИТ-ресурсов и технологий предприятий, они могут и должны выступать регуляторами и организаторами движения к SOA. Взаимопонимание с бизнесом в этом вопросе, безусловно, существенно влияет на общий результат SOA-проектов.
Ярослав Медокс: Полностью согласен. Это фундаментальная причина, в силу которой именно ИТ-подразделение может и должно заниматься структурированием процессов.
Владислав Боркус: За исключением бизнесов, серьезно завязанных на ИТ, вес ИТ-подразделения в компаниях не высок. Например, при выборе сложной прикладной системы (скажем, ERP), «политический» вес руководителя функционального подразделения обычно оказывается значительно больше веса ИТ-директора. Да, согласен, ИТ-директор может взяться за структурирование существующих процессов, просто поскольку никто другой этим не занимается. Но инициировать и реализовать какие-то серьезные изменения — это вряд ли, него для этого нет достаточного веса. С другой стороны, я видел предприятия, где описанием процессов занимается отдел качества, и это вполне удачно получается.
Фарид Сулейманов: Мышление людей бизнеса и ИТ-специалистов различается. Первые мыслят фактами и процессами реального мира, вторые — структурами и процессами «автоматизированного» мира. Ведь по сути в результате автоматизации получаются некие конечные автоматы (программы), которые действуют с определенной жесткой логикой. А бизнес мыслит поверх и часто вне этой логики.
Если в бизнесе есть люди, способные строить модели своих процессов, заинтересованные в анализе результатов их исполнения, а в ИТ — люди, готовые за реализацией этих моделей видеть реальные бизнес-потребности, то возникает «вертикальная» технологическая связка бизнес — ИТ, которая дает большой эффект для продвижения на пути к SOA. Именно к такому взаимодействию необходимо стремиться.
Дмитрий Грязнов: Идея управления бизнес-процессами — BPM — отчасти похожа на распропагандированный некогда реинжиниринг бизнес-процессов, когда консультанты приходят, говорят: «В вашем бизнесе все неправильно организовано, и мы сейчас все поправим» — и начинают менять. Этот подход себя не оправдал, но подход BPM несколько иной. Да, это снова «квадратики» модели бизнес-процессов, но бизнес смотрит на них и говорит: «Так вот как у нас все происходит, а если мы вот тут подвинем, а здесь уберем, то что будет»? Такое совместное описание и моделирование дает значительно лучшие результаты. А если умный ИТ-директор вовремя скажет: «А давайте, мы эту модель привяжем к реальным ИТ-системам, посмотрим, как поёдет», — то получится еще лучше. Поэтому обе инициативы — и SOA и BPM — оказываются более успешными, если проводятся совместно, тогда эффект от них складывается.
Intelligent Enterprise: Если ИТ-отдел должен быть инициатором SOA-проектов, то возникает задача финансирования и утверждения ИТ-бюджета. Как строится обоснование SOA-проектов?
Дмитрий Грязнов: От нас однажды потребовали, чтобы мы оценили возврат инвестиций от реализации двух сервисов. Ну как это измерить? Причем эти оценки нужно было показать ИТ-подразделению и бизнесу. Для ИТ мы сделали просто: замерили некие метрики процесса в начале и в конце проекта. Потом пошли к ИТ-директору и сказали: смотри, у тебя за год на 20% выросло использование сервиса. Значит, можно пойти к начальству и на этом основании попробовать получить больше средств. А с финдиректором разговор был другой: мы показали ему, как один сервис используется в каждом подразделении, и предложили расходы на оплату этого сервиса разделить между ними пропорционально использованию. В этой компании был введен внутренний хозрасчет, поэтому такой подход финдиректору был близок и понятен.
Ярослав Медокс: Я не согласен. Казалось бы, действительно можно сравнить метрики — скажем, сколько времени проходила заявка до проекта и после, — и посчитать ценность этого проекта на основании таких замеров. Но в реальности сделать это невозможно. Ведь параллельно идет изменение процессов управления, и за счет чего получен эффект, сказать нельзя. И одновременно увеличивается число сервисов, подключенных к шине.
Фарид Сулейманов: С бизнесом надо разговаривать на его языке. Есть понятия KPI бизнес-процессов, например затраты на единицу операции, ROI и т. д. Если мы создаем сервисную шину ESB с универсальными, повторно используемыми сервисами, то мы снижаем общие затраты и риски. Если мы автоматизируем процессы и наглядным образом представляем все необходимые бизнес-характеристики (метрики) этих процессов, то возникает обратная связь, при которой бизнес будет заинтересован в управлении этими характеристиками, в их оптимизации. Поэтому, кстати, очень важны не только системы разработки бизнес-процессов, но и системы бизнес-мониторинга. Причем мониторинг должен закладываться на стадии проектирования процессов.
Полноценный ROI таких проектов подсчитать очень сложно, поэтому обычной практикой является сопоставление планируемого дохода от проекта (business value) и затрат на ИТ. Именно поэтому трудно делать «пилоты» по SOA: если выбирается небольшая задача, то у нее, как правило, не очень большой ожидаемый бизнес результат, а для ее исполнения необходимы довольно высокие затраты (например, приобретение лицензий). Если же идёт дорогостоящий и критичный бизнес-проект, то это означает жесткие сроки и жесткий проектный подход: «Никаких экспериментов!».
Поэтому для того чтобы получить средства на проекты по развитию SOA, надо опираться на знание потребностей бизнеса и прогнозирование его реакции. Хороший аргумент — производительность и надежность систем. Любой бизнес хочет иметь надежные и высокопроизводительные технологические ИТ-сервисы. Если ИТ отслеживает и представляет бизнесу соответствующие метрики этих сервисов, то на определенном этапе он сможет сказать: «Мы не сможем обеспечить планируемые потребности бизнеса по производительности и надежности систем, если не перейдем на новое качество их реализации». Другим аргументом может быть ускоренное внедрение изменений в информационной системе в соответствии с ожиданиями бизнеса (не годы, а месяцы и даже недели).
Ярослав Медокс: Мы пользовались тем же приемом. Просто говорили: начиная с определенного момента ИТ-системы работать не смогут, мы просто не переживем Новый год. В банковском бизнесе вся менеджерская команда должна понимать, что они полностью зависят от ИТ. И надо требовать от них и понимания того, какие ограничения накладываются действующими ИТ-системами. На мой взгляд, не надо продавать бизнесу саму SOA. И не надо говорить, что нам надо построить SOA. Надо говорить, что необходимо построить такой-то сервис, потом еще один, потом еще.
Сейчас мы приняли общебанковскую проектную методологию, разработали документы, организовали проектный комитет, и сейчас уже становится видно, на какие проекты мы тратим деньги, видны узкие места. И я могу говорить — вот, если бы тут был сервис, тогда это стоило бы дешевле. А цену каждого сервиса мы скоро сможем посчитать. Это будет возможно, когда будет больше сервисов.
Intelligent Enterprise: Какова реальная практика перехода к SOA? Как можно спланировать этот подход?
Ярослав Медокс: На мой взгляд сначала для SOA надо выбирать ИТ-проекты с низкой степенью риска и гарантированно выигрышные решения. Как, например, двигались мы. Прежде всего просто прописали в ИТ-стратегии: мы строим SOA. И поскольку ESB — это фундамент SOA, то мы внедрили IBM WebSphere ESB. Инициатива при этом исходила от ИТ-подразделения. А начав думать в этом направлении один раз, потом будешь постоянно расматривать проблемы с точки зрения SOA. Затем возникла очень сложная задача — сделать в рамках одной кредитной карточки и одного счета две части: целевой кредит с определенной кредитной ставкой и револьверный кредит. Причем внедрить это нужно было за три месяца, а в банке работают две разные системы операционного дня — Way4 и «Диасофт», и поменять их нельзя, тем более в такие сроки. И вот при помощи интеграции, через обмен сообщениями на базе ESB, мы их и «подружили».
Владислав Боркус: А через традиционную интеграцию приложений нельзя ли было сделать то же самое?
Ярослав Медокс: Во-первых, у этих приложений совершенно разные модели данных, и одно из них не имело никаких средств интеграции. Во-вторых, кроме них было еще три-четыре системы, которые необходимо было связать в рамках этого проекта. До этого без проблем работал файловый обмен между ними, но внедрив сервисную шину, мы вдвое подняли скорость их взаимодействия, просто попутно.
Наконец, в-третьих, такой же сервис мы могли бы сделать в рамках одной системы Way4, но это потребовало бы серьезного программирования. У нас еще есть целевой проект внедрения одной банковской американской системы для автоматизации бэк-офиса, и мы по-прежнему собирались выполнять каждый класс операций в своем приложении: карточку считать в одной системе, кредиты в другой, и т. д. При такой реализации системы эти два приложения остаются в своих функциональных границах.
Фарид Сулейманов: А наш проект начинался с осознания архитектурных проблем в информационной системе банка, в которой развернуты десятки систем и приложений, сотни интерфейсов, используется очень много платформ. В принципе все системы работали нормально, но бизнес поставил амбициозные планы по росту своих показателей, и нам было ясно, что при существующей архитектуре мы не сможем обеспечить общую работоспособность систем в будущем.
Тогда было решено внедрить централизованную интеграционную платформу для перевода на нее наиболее критичных интерфейсов. Мы выбрали платформу IBM WebSphere Message Broker, причем вначале ее внедрение не рассматривалось как проект SOA.
По мере реализации централизованных интерфейсов вставали вопросы стандартизации взаимодействия, и параллельно возникла потребность в новых сложных бизнес-процессах, связанных с розницей. На стыке этих двух направлений нам стало ясно, что проект интеграции необходимо рассматривать именно через призму подходов SOA, то есть внедрять ESB, использовать универсальные протоколы интеграции, разрабатывать универсальные сервисы. Сейчас мы стоим на пороге внедрения процессно-ориентированной разработки. Мы понимаем, что надо делать этот следующий шаг — строить модели процессов, внедрять разработку на платформе BPEL, применять средства мониторинга BAM. Таким образом, мы идем к SOA «снизу», с поэтапного решения реальных проблем.
Ярослав Медокс: Мы движемся в том же направлении. Этой осенью заработает пилотный проект на IBM WebSphere Process Server, затем мы постепенно перенесем часть кредитов из одной прикладной системы в другую. Сейчас кредитные подразделения имеют четкий workflow, ясную модель процессов, и возникает естественное желание попутно оптимизировать и их. Идет миграция с одного приложения на другое, и делается это легко. Обе системы подключены к шине данных, и заявки все больше и больше переходят на новую систему. Пока старая система остается рабочей, из нее уходят только скоринговые функции. Но со временем мы откажемся от нее полностью.
Дмитрий Грязнов: У нас в работе несколько проектов такого типа. Мы движемся через «пилоты», тоже постепенно. Например, есть конкретная проблема — MES-системы, которые нужно интегрировать с ERP. Это частный случай, но мы решили использовать ESB, создали ядро. А теперь готовы распространить ESB и на остальные ИТ-системы предприятия.
Фарид Сулейманов: Консультанты по вопросам SOA говорят: «Берите реализуемые проекты, решайте то, что можете решить». При этом должно быть постоянное движение в цикле выбор задачи — постановка — решение — анализ — отчет, потом следующая задача и так далее. «Не пытайтесь вскипятить океан» — таков, в частности, тезис консультантов из Gartner. И это правильно: должны быть представители со стороны бизнеса (и чем выше по уровню принятия решений, тем лучше), которые могут понять и оценить эффект внедрения SOA. Но нужно быть готовыми к тому, что все это будет стоить недешево и, возможно, на первых этапах будет продвигаться не так быстро, как хотелось бы.
Intelligent Enterprise: Сколько сервисов уже реализовано в ваших проектах, как вы их выделяли и как выбираете те, что можно использовать повторно?
Ярослав Медокс: Чтобы выделять такие сервисы, надо анализировать процессы. Методология подсказывает, как ранжировать существующие сервисы, чтобы выделить среди них повторно используемые, но вот как именно их выделять изначально — по этому поводу нет четких рекомендаций. Пока сервисов у нас немного. Несколько из них обеспечивает система «Диасофт» — открыть счет, проверить кредитную историю, ввести договор, сделать проводки… Когда сервисов будет сто, тогда реальную значимость каждого просчитать будет легче. Пока же это сложно, но некоторые вещи уже идут «на ура». Например, недавно подключили к шине два новых сервиса, потом быстренько подстроили workflow и сразу стали проверять кредитные истории с их помощью. А я даже не знал об этом, пока не увидел в отчете.
Фарид Сулейманов: На начальном этапе в рамках проекта оптимизации интерфейсов с использованием интеграционной платформы WBI мы реализовали более двадцати задач интеграции, включающих около сотни потоков взаимодействия приложений. В основном эти задачи относятся к сервисам репликации справочных и учетных данных.
В рамках проекта централизованных Web-сервисов разрабатывается и внедряется более сорока Web-сервисов доступа к API банковского ядра, которые будут использоваться различными системами. На следующих этапах мы планируем разрабатывать композитные, т. е. более сложные сервисы, использующие сервисы элементарные, уже готовые. Есть также направление SOA-интеграции приложений розничного бизнеса — внедрен сложный асинхронный Web-сервис, обеспечивающий интеграцию фронт-офисных систем розничного банка с подсистемами скоринга и верификации клиентов при оформлении кредитных продуктов Перспективным направлением для нас является разработка сервисов, которые определяются в результате анализа различных бизнес-процессов. Подход такой: мы описываем (моделируем) процессы, выделяем в них повторяющиеся бизнес-функции, реализуем эти функции как сервисы, которые затем используем при имплементации процессов на платформе BPEL.
Дмитрий Грязнов: Наш опыт показывает, что выбор бизнес-сервисов сложен и занимает много времени при предпроектном исследовании. Инфраструктурные — тут все понятно, но бизнес-сервисы, которые можно было бы использовать повторно, выделить очень сложно. Наш расчет на то, что их выделят сами клиенты, не оправдывается — они не знают этого. Анализируя средний банк, мы насчитали около 180 только ключевых бизнес-процессов, а попытки дождаться от бизнеса указаний на то, какие именно бизнес-сервисы нужно выделять, успехом не увенчались.
Тогда мы решили делать так: предлагаем компаниям выделить три самых важных процесса, где постоянно есть проблемы, «узкие» места. И смотрим, в чем именно они состоят. Иногда бывает просто: человек не успевает что-то сделать. Обычно это какие-то комплексные запросы, которые делает конкретный сотрудник, и вот именно их и можно выделить как сервисы.
Приведу пример. Некий частный пенсионный фонд имеет четыре базы с информацией о контрагентах. Их нужно по определенным правилам свести все вместе, установить взаимодействие между полями. Раньше это делалось вручную. Мы выделяем сервис, скажем «проверку контрагента» — когда сотрудник вводит фамилию контрагента и получает всю информацию по нему, причем если какие-то величины не укладываются в заданный диапазон, то они выделяются красным. Это было сделано, а потом совершенно случайно выяснилось, что этим же сервисом пользуется и бухгалтерия, только там нужны другие поля, а идея та же самая. Мы немного переделали сервис — с программной точки зрения это просто, и, видимо, тот же механизм будет использоваться и в других местах.
Фарид Сулейманов: Для выявления сервисов можно использовать следующий подход: выделить в информационной системе объект данных и искать все функции и бизнес-роли, которые к нему обращаются, т. е. проводить анализ типа «кто и как смотрит и изменяет эту информацию?». Таким образом можно выделить сервисы, не делая описания для действующих бизнес-процессов. И чем больше их будет выявлено, тем легче будут проявляться сами процессы, которые затем можно описать и оптимизировать.
Владислав Боркус: Еще один способ выделения сервисов — проанализировать, как интегрированы приложения, ведь SOA приходит не на пустое место. Однако никакие способы не дают гарантированного результата. Например, есть статистика повторного использования сервисов, которая собиралась для некоторых проектов SOA, выполненных еще на базе технологии CORBA. Получается, что коэффициент повторного использования сервисов составляет примерно 1,6. Хотя самые удачные сервисы могут использоваться десять и более раз.
Дмитрий Грязнов: Только обширная практика позволяет выработать эффективную методологию выделения сервисов, а её-то как раз пока очень мало. С ERP-системами Россия опоздала лет на восемь по сравнению с западным миром, с интеграцией — года на четыре, а в SOA мы сейчас на том же уровне, что и Запад, поэтому и нет реального опыта.
Константин Жуков: Последняя версия решения SAP Business Suite содержит больше тысячи выделенных и описанных корпоративных сервисов, в том числе свыше пятисот — в рамках SAP ERP. Более подробную информацию об этом можно получить на сайте www.sdn.sap.com. Кроме этого мы предлагаем своим клиентам консалтинговую услугу, которая называется «Разработка программы перехода к корпоративной SОА» (eSOA Adoption Program). Эта инициатива осуществляется в рамках формализованной методологии, включает несколько этапов и позволяет, учитывая соответствие бизнес- и ИТ-стратегии компании, решить целый ряд задач, в частности определить план перехода к корпоративной SОА, выделить перспективные области и непосредственно корпоративные сервисы, показать реализуемость в рамках пилотного проекта, а также дать качественную и количественную оценку преимуществ от использования концепции Enterprise SOA.
В России уже более десятка компаний воспользовались данной услугой и осуществляют дальнейшие шаги по переходу на корпоративную SОА.
SOA — это свобода от жесткой архитектуры
Борис Славин, член правления СоДИТ, ИТ-директор НПФ «Благосостояние».
Какие причины, с вашей точки зрения вызвали к жизни SOA?
На мой взгляд, появление сервисно-ориентированного подхода — это реакция на ту архитектуру информационной системы, которая пропагандировалась последние лет десять. Это архитектура ИС, базирующаяся на единой комплексной автоматизированной системе от одного поставщика, известной как ERP-система (системе учета и планирования ресурсами предприятия). Идея автоматизации на основе ERP-систем не умерла даже тогда, когда выяснилось, что планированием и учетом ресурсов не ограничивается информационная система предприятия (необходимо управлять еще и взаимоотношениями с клиентами, решать задачи стратегического менеджмента и т.д.). Когда выяснялось, что ERP-система не покрывает всех необходимых процессов, появился (с легкой руки Gartner) новый термин - ERP II, куда включались и другие необходимые функциональности, например, CRM-система. Но даже, если удается автоматизировать учет и планирование предприятия на едином продукте в рамках расширенного стандарта ERP II, все равно охватить всю функциональность, особенно крупного, предприятия не удается — в частности в ERP, как правило, не реализуется базовый уровень управления производством или услугами, являющимся специфичным для разных отраслей.
Возникает справедливый вопрос «а надо ли вообще пытаться все реализовать на едином продукте»? Нужен ли вообще такой подход самому бизнесу. Безусловно, единство информационного пространства необходимо, нельзя скатиться к «кусочной» автоматизации. Поэтому на первый план должны быть поставлены задачи интеграции: развивать автоматизацию по отдельным функциональным направлениям, выбирая продукты наиболее отвечающие потребностям бизнеса, но связав их общей шиной и стандартами, которые позволяют не потерять взаимосвязи между отдельными системами. Стандарт SOA не означает отказа от единого продукта, объединяющего различные функциональности, но он допускает возможность использования продуктов от разных поставщиков, давая ИТ-директору неизмеримо больше возможности в построении информационной системы предприятия.
То есть с вашей точки зрения это технологическое движение, связанное именно с несовершенством технологий?
Нет, мне кажется, что проблемы связанные с ERP-подходом как раз и показали, что чисто технологический подход к решению задач автоматизации невозможен. Ведь проблемы реализации ERP-подхода лежат не в технологической плоскости. Бизнес компаний строится везде очень по-разному, а ERP-подход предполагал по сути одну централизованную модель бизнеса. И проблемы с внедрением ERP-систем были связаны, прежде всего, с тем, что эту модель пытались «натянуть» на реальные бизнесы.
В связи с этим я думаю, что SOA — это вообще не технология, а скорее подход. Ведь понятие общей шины — отнюдь не новое, а хорошо забытое старое. Но важно, что оно отпускает вожжи, дает свободу в области построения архитектуры информационной системы, но при этом требует работать в рамках единых стандартов. Общая шина может быть реализована как на базе интеграционной платформы, и тогда мы получим более жесткую конструкцию информационной системы, а может предъявлять довольно поверхностные и мягкие требования например на уровне стандартов предоставления отчетной информации, что специфично для управляющих компаний крупным холдингов. Реализации зависят от непосредственных задач управления бизнесом. Поэтому SOA я рассматривал бы именно как отмену жесткой архитектуры. SOA — это подход, который дает свободу в выборе архитектурного варианта.
Аббревиатура SOA — не лучшим образом отражает суть самого подхода, на мой взгляд, лучше новый стандарт назвать бизнес-ориентированной архитектурой. Однако смысла и в таком названии большого нет — ИТ по определению должны быть ориентированы на бизнес. Возможно, название SOA возникло для того, чтобы не конфликтовать со старым ERP-подходом. Ведь SOA не отменяет стандартный ERP-подход в тех случаях, когда это оправдано.
К сожалению, мне кажется, мы слишком привыкли к трехбуквенным аббревиатурам и пытаемся мыслить в этих категориях, искать в сокращениях сокровенный смысл. ИТ-директор подчас занят исключительно анализом того, что изготовили вендоры, что и как включили в свой трехбуквенный продукт, а что не включили. Вместо того, чтобы участвовать равноправно в решении бизнес задач предприятия, ИТ-директор занят проблемами внедрения продукта. SOA дает возможность ИТ-директору в первую очередь заняться нуждами бизнеса, поставив проблему выбора продуктов на второй план. Мне кажется, что трехбуквенная аббревиатура SOA означает окончание эры трехбуквенным сокращений. Это начало нового этапа, когда ИТ-директор должен перестать быть специалистом в программных продуктах, представленных на рынке, а стать реальным технологом бизнеса, где он работает.
Intelligent Enterprise: Давайте перейдем к другим критичным моментам SOA-проектов. Что здесь критично — выбор платформы? Или, может быть, то, что SOA-проекты требуют особого подхода к формированию команды и управлению ею?
Фарид Сулейманов: На мой взгляд, выбор платформ (имея в виду платформы от разных производителей) для SOA не так уж критичен. Функциональная зрелость многих продуктов находится на близком уровне. Да, лидерство отдельных производителей возможно, но только в какой-то отдельный период и по определенному направлению. А так как проекты идут долго, за это время ситуация на рынке часто меняется. Эффективными могут быть платформы любого производителя, важно только с самого начала правильно оценить как функциональные потребности при их использовании, так и необходимость масштабирования интегрируемых систем. На выбор больше могут влиять корпоративные стандарты по применяемым платформам, а также ограничения по затратам на лицензии.
Дмитрий Грязнов: Я бы очень внимательно подходил к выбору, учитывая имеющиеся приложения, данные, количество транзакций, структуры их взаимодействия. Выбор платформы — это очень важное решение, которое повлияет на весь дальнейший проект.
Фарид Сулейманов: Гораздо важнее, что к SOA-проекту потребуются другие подходы. Проектные команды здесь должны быть организованы иначе, чем в традиционных ИТ-проектах. Обычно команды проектов (менеджеры, аналитики, разработчики) организованы вертикально и хорошо работают на известных им платформах, в привычном технологическом окружении. Типичный ИТ-проект имеет четкие границы определения задачи (scope), и в этих рамках выбираются как сами решения, так и их поставщики (а чаще один поставщик), проекты стремятся ограничить взаимодействие друг с другом, чтобы снизить риски. В SOA-проекте нужна открытая организация с акцентом на структурированное взаимодействие с другими командами и проектами, нужны люди, способные к широкому и энергичному взаимодействию, готовые учиться, но при этом обеспечивать результат. Это относится как к внутренней команде, так и к внешним ресурсам, и об этом нужно думать с самого начала SOA-проекта.
Ярослав Медокс: У меня данный вопрос решился просто: отправили людей на курсы в IBM. В нашей компании есть должность главногосистемного архитектора, который диктует стандарты и проверяет качество работы системных архитекторов в проектах. Подрядчиками он не управляет, этим занимаются другие — тут абсолютно разные роли. Но при жестком управлении мне даже удается удерживать этот интеграционный проект в соответствии со схемой «time and material», хотя очень трудно, особенно на начальной фазе, прогнозировать и риски его, и сроки.
Планирование по SOA-проекту ведётся еженедельное — постановка задач, трудозатраты… И этот интеграционный проект имеет отдельный бюджет. Постепенно я переключаю наших разработчиков, чтобы они вместе с внешними участвовали в создании сервисов, перенимая у них экспертизу. При этом бизнес-заказчиков в команде SOA-проекта у нас нет — только мы и подрядчики. Бизнес подключается лишь при разработке отдельных сервисов, тех, что содержат наибольшую долю интеграционных задач, но не является постоянным членом команды проекта.
Фарид Сулейманов: У нас тоже бизнес-пользователи пока не участвуют непосредственно в SOA-проектах. Они выдвигают требования, как правило, неструктурированные, на основе которых выполняется цикл проектирования и разработки. Для реализации SOA-проектов мы также привлекаем аутсорсинговую компанию. Важно отметить, что если в обычных проектах, формализовав функциональные требования к системе, мы передаем их разработчикам, то в проектах SOA эта стандартная схема неэффективна. Здесь проектирование и разработку нужно выводить на уровень понимания бизнес-процессов. Обычно менеджер каждого ИТ-проекта, вначале определив его функциональные рамки (scope), в дальнейшем жестко работает только в этих интересах. Так, собственно, и возникают монолитные приложения. Мы внедряем подход, при котором задача должна решаться не только в соответствии с пониманием функциональности бизнес-задачи, но и в соответствии пониманием бизнес-процессов, которые эта функциональность реализует. В каждой задаче необходимо определять как используемые готовые сервисы, так и новые, разрабатываемые. Следует заметить, что если не контролировать общую сервисную архитектуру и подходы, то даже в тех случаях, когда к реализации отдельных задач привлекаются «продвинутые» команды SOA-разработчиков, , можно получить монолитное по сути приложение, реализующее внутри себя самые передовые технологии. Принципиальный момент в управлении SOA-проектом заключается в том, что разработку отдельных компонентов (т. е. отдельных сервисов и собственно самих «нитей» процессов) необходимо разделять на отдельные потоки реализации с разными разработчиками. Такой подход организационно сложнее обеспечить на начальной стадии проекта, но в ситуации, когда в дальнейшем нужно будет быстро изменять и настраивать автоматизируемые бизнес-процессы, это даст выигрыш в сроках и снизит риски. Практически мы должны перейти к новой парадигме управления проектами ИТ-разработки.
Константин Жуков: Весьма критичной является готовность информационного ландшафта предприятия поддерживать SOA-концепцию — то есть способность уже внедренных систем обеспечивать доступ к функциональным блокам и данным на основе открытых стандартов.
Второй момент — готовность ИТ-департамента и бизнес-подразделений к взаимодействию на другом уровне. Речь идет и о знаниях и понимании данной концепции, и об организационной структуре ИТ-департамента, способной поддерживать разработку приложений на основе сервисов и модели бизнес-процессов.
Критически важно в рамках перехода к SОА создать единую систему управления НСИ. Только наличие единого, актуального и непротиворечивого источника научно-справочной информации позволит реализовать интегрированный процессный подход с использованием сервисов, предоставляемых различными системами, каждая из которых «исторически» оперирует своими справочниками и классификаторами. Таким образом, в рамках концепции SОА единая система управления НСИ сама должна быть источником сервисов для различных бизнес-процессов.
Фарид Сулейманов: Я бы хотел добавить два замечания. Первое: не надо забывать о вопросах производительности и масштабирования систем. Можно, например, в рамках SOA-интеграции создать универсальный сервис, который будет обращаться ко многим системам, но при определенной нагрузке он просто перестанет удовлетворять требованиям бизнеса по времени обработки. Нужно учитывать, что SOA-решения во многих случаях могут быть менее производительными, чем традиционные частные системы, и поэтому необходимо обеспечить соответствующее масштабирование интеграционных платформ (ESB, BPE и т. д.) и, возможно, реинжиниринг действующих приложений. И второе: в сервисно-ориентированной архитектуре за счет централизации усиливается взаимозависимость различных бизнес-подразделений через используемые общие данные. SOA не отменяет и сама по себе не решает проблему управления данными. Следовательно, она должна развиваться параллельно с подходами по управлению данными транзакционных систем — Master Data Management, впрочем, как и с другими подходами концептуальной модели архитектуры предприятия .
Дмитрий Грязнов: В целом работать с сервисами сложней, чем с традиционными приложениями. Требования к их надежности должны быть выше. Намного труднее отслеживать работу многочисленных сервисов, ведь их нельзя останавливать, они все время востребованы и, следовательно, нуждаются в постоянном и очень четком тестировании. Возникают совсем другие, более жесткие требования к сотрудникам ИТ-подразделения, которые этим занимаются. Хотя им не всегда бывает понятно, для чего эти сервисы: бизнес и так получает всю запрашиваемую информацию.
Ярослав Медокс: Как раз поэтому мы написали специальный документ, где ИТ-специалистам разъясняется, что такое сервис, зачем нужна SOA и как всё это должно выглядеть. Без такого рода разъяснений на всех этапах проекта просто не обойтись.
SOA — это модный ярлык для структурирования бизнеса
Игорь Ковалев, ИТ-менеджер, Ford of Russia.
С моей точки зрения SOA — это модный ярлык для структурирования бизнеса. И здесь мне близки слова Фарида Сулейманова: "есть очень хорошие документы OASIS, которые определяют SOA так, что ИТ вообще не упоминается. Есть только примеры ИТ-имплементации, а все остальное — общий подход к организации любой системы." Никакие ИТ-технологии, основанные на веб-стандартах или нет, не помогут автоматизировать хаос, поэтому рассмотрение SOA в ИТ в отрыве от бизнеса, без попытки декомпозиции бизнес-процессов не принесут результатов.
Вопрос о том, кто должен лидировать развитием ИТ систем — ИТ или бизнес — по сути один из фундаментальных вопросов во взаимодействии бизнеса и ИТ. С моей точки зрения — только вместе. Любой другой вариант ведёт к потере эффективности и перекосам.
Не могу согласиться с тем, что для компаний со стабильным бизнесом SOA не нужна. Если бизнес стабилен, это ещё не значит, что он уже структурирован и проанализирован, разделён на сервисы в оптимальном виде. И меняющаяся окружающая среда всегда будет изменять уровень оптимальной декомпозиции для того или иного процесса. Кроме того, любая компания никогда не останется навечно вне конкуренции, основного двигателя прогресса.
Если бизнес-процесс уникален и не повторяем, то можно выделать его как отдельный сервис и рассматривать как неделимую единицу. С этой точки зрения почти в любой ситуации может использоваться подход SOA — в одних случаях, как кирпичик, в других случаях, как здание, состоящее из кирпичиков-сервисов. Здание бизнеса всегда имеет ту, или иную архитектуру. Вопрос только в том, что мы берём за кирпич или плиту-сервис в том или ином случае. И в какой момент его необходимо переставать и делить существующий процесс на отдельные сервисы.
