Rambler's Top100
Статьи ИКС № 4 2008
Елена ЗЕЛЕНИНА  Дмитрий Анатольевия ПОВАРОВ  07 апреля 2008

Как не разминуться в туннеле

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

Дмитрий ПоваровЕлена ЗеленинаФактически SOA воплощает давнюю мечту бизнес-консультантов и системных интеграторов: не разрабатывать приложения с нуля, а собирать информационные системы (ИС) из неких «стандартных кубиков» в соответствии с реальными бизнес-процессами заказчика, а впоследствии – предоставить заказчику возможность самому осуществлять такую «сборку». Для этого у SOA есть два неоспоримых преимущества: 1) возможность выделить «кубики» с функционалом, который необходимо обособить, и с набором функций, доступным конечному пользователю; 2) возможность с помощью технологий управления бизнес-процессами (BPM) выделить и структурировать (даже в графическом виде) бизнес-процессы заказчика, а потом реализовать их с помощью «стандартных кубиков» и некоторой бизнес-логики. Причем если в бизнес-процессах по каким-либо причинам произойдут изменения, их можно будет быстро отразить в ИС.



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


Ключ к SOA
                       
Еще один ключевой элемент практической реализации SOA – сервисная шина (Enterprise Service Bus, ESB), представляющая собой верхний уровень абстракции службы обмена сообщениями. Именно на ESB размещаются стандартные интерфейсы для обращения к сервисам, при этом механизмы оказания самих сервисов пользователю безразличны и скрыты от него.                                                                                                            
                                                                                                                                                                                                                                                                                      
Основу ESB составляет технологический сервис передачи сообщений и управляемая этими сообщениями система исполнения бизнес-логики. Сервис передачи сообщений обеспечивает обмен информацией между потребителями и поставщиками сервисов, а слой бизнес-логики реализует сервисы, активируя их работу при поступлении сообщений. При реализации сервисов могут использоваться как внутренние процессы данного слоя ESB, так и обращения к внешним ИС посредством специально разработанных интерфейсов-адаптеров, позволяющих «достучаться» до этих систем в терминах их бизнес-логики и получить доступ к бизнес-объектам.                                                                                             
                                                                                                                                                                                                                                                                                      
Таким образом, интеграционная сервисная шина позволяет строить бизнес-процессы, которые могут использовать обращения к различным ИС и бизнес-приложениям. Более того, событие, произошедшее в одной системе, может с помощью реализованной бизнес-логики породить событие в другой системе. Например, в CRM регистрируется новый пользователь, а соответствующие объекты для него появляются в биллинговой системе.



Концепция бизнес-сервисов

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

Первый слой – технологический – представляет собой шину для обмена сообщениями, в которой реализованы некоторые технологические бизнес-процессы. Например, в автоматизированной системе оператора связи, включающей в себя подсистемы биллинга и CRM, – это регистрация абонента, проверка наличия абонента в системе, синхронизация информации об абоненте в биллинге и CRM, регистрация платежа, формирование образа счета, получение информации о балансе, регистрация тарифа и т.д.

Второй слой – собственно сервисы, реализующие бизнес-процессы компании. В качестве примера можно привести процедуру создания нового продукта: разработку драфта, его обсуждение, редактирование, согласование, утверждение, внедрение, тестирование. Автоматизируют эти процессы, как правило, продукты класса BPM, интегрируемые с решениями технологического слоя. Примечательно, что, когда говорят о SOA, обычно имеют в виду именно эти процессы. Документооборот между бизнес-процессами организован с помощью сервисов на уровне BPM; при этом бизнес-процессы и «высокоуровневые» сервисы обращаются к сервисам технологического слоя. Пример – процедура регистрации нового тарифного плана в биллинговой системе. Если план одобрен и должен быть использован в биллинговой системе, то соответствующие «высокоуровневые» сервисы обратятся к сервисам технологическим и новый тариф будет занесен как в биллинг, так и в CRM.

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

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

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

Таким образом, концепция бизнес-сервисов предусматривает создание некоего стека, только построенного не строго вертикально, а организованного за счет так называемых механизмов позднего связывания (или «слабых связей»). Это означает, что интеграция компонентов ИС выполняется не на этапе программирования интерфейсов, а после – путем объединения готовых интерфейсов отдельных систем в рамках заданного комплекса бизнес-процессов.

Выделение бизнес-сервисов

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

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

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

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

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

Конечно, наиболее эффективен при выделении набора веб-сервисов двусторонний процесс: использование услуг экспертов в области управленческого консалтинга для формализации и оптимизации бизнес-процессов плюс интеграция систем и бизнес-приложений на основе выделения потоков данных. Выделение потоков данных в проектах оптимизации бизнес-процессов компании позволяет существенно экономить ресурсы предприятия (время проведения и стоимость услуг консалтинга). Оптимальным решением будет «встречное движение» бизнес-консультантов и специалистов в области интеграции программных продуктов. Вопрос только в том, встретятся ли «строители туннеля» в нужной точке или каждый будет прокладывать в горной породе свой путь?

Способы интеграции приложений

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

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

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

Очередной этап развития – сервисная шина, которая также объединяет некоторые приложения, но они вовсе не «осведомлены» друг о друге. На шине есть набор сервисов, которые можно «позвать». Что происходит дальше, приложениям не важно, главное – они получат то, что ожидают. Фактически приложения обращаются именно к сервисам. Несомненное преимущество этого способа – включение внутренней логики обработки, наличие элементарного преобразования информации.

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

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

За пять лет до эры SOA

По нашим оценкам, полноценное воплощение SOA в ИС российских предприятий пока не стало актуальной задачей. Процессы, происходящие сейчас на отечественном рынке, можно назвать лишь движением к SOA, или предвестниками эры SOA. Но, скорее всего, лет через пять SOA будут использовать большинство крупных и распределенных компаний, поскольку так проще и экономически выгоднее строить ИС для бизнеса.

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

Особенности интеграционной платформы

Сегодня на рынке представлено множество интеграционных платформ от разных производителей. Свои продукты предлагают IBM, SAP, Oracle, BEA systems, а также недавно вышедшая на российский рынок компания TIBCO.

Решения TIBCO для интеграции приложений и оптимизации самого бизнеса представлены во всех описанных нами слоях SOA. Для реализации технологического слоя TIBCO предлагает решения для построения «сервисной шины» (TIBCO Enterprise Messaging Service и TIBCO Hawk – Monitoring and Management), а также комплекс решений для полномасштабной интеграции бизнес-приложений (TIBCO BusinessWorks (EAI), TIBCO BusinessConnect (B2Bi), TIBCO Adapters, Enterprise Metadata Management). Такой набор программных продуктов позволяет внедрить интеграционную платформу в любой конфигурации, удовлетворяющей текущим потребностям его бизнеса. В будущем это решение может развиваться и дополняться.

Второй уровень SOA в спектре предложений TIBCO представлен решением класса BPM для управления бизнес-процессами (TIBCO Staffware Process Suite), а также продуктами и технологиями оптимизации бизнес-процессов и самого бизнеса заказчика (TIBCO PortalBuilder, TIBCO BusinessFactor, TIBCO BusinessEvents). Эти решения позволяют правильно и в полной мере выделить бизнес-сервисы, на которых базируются реальные бизнес-процессы компании, оптимизировать их и построить систему управления ими. Такие продукты становятся необходимы, когда в компании уже реализован процессный подход к работе, формализованы бизнес-процессы и выделены бизнес-сервисы. До того момента заказчик может ограничиться интеграцией своих бизнес-приложений с помощью решений TIBCO для технологического слоя SOA – интеграционных платформ.


Пример удачного использования интеграционной платформы TIBCO – проект создания автоматизированной системы расчетов за услуги дальней связи в «Компании ТрансТелеКом» (рисунок), реализованный компанией «Микротест» в 2007–2008 гг. (см. «ИКС» № 3'2008, с. 20). В нем для интеграции ряда подсистем от разных вендоров и включения всего комплекса в единое информационное пространство ТТК было использовано решение TIBCO Business Works – интеграционная сервисная шина масштаба предприятия (ESB).
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!