Аналитики, лидеры индустрии и поставщики программного обеспечения много пишут о сервис-ориентированной архитектуре (Service Oriented Architecture, SOA) и о том, почему этот подход стал основным при проектировании архитектуры информационных систем предприятия. Под SOA здесь подразумевается концепция, в рамках которой приложение строится из набора готовых компонентов - "кирпичиков", часть из которых уже существует на предприятии, а часть предоставляется внешними поставщиками сервисов. Основным преимуществом такого подхода является типизация компонентов ИТ-решений и возможность быстрого перестроения приложения в случае необходимости. Однако в области SOA существует несколько вопросов, которые являются центром дискуссий вокруг данной концепции.
При использовании многих приложений логика и правила выполнения большинства бизнес-процессов могут быть отделены от собственно реализации приложений. Отделение логики процессов позволяет изменять поддерживаемые приложением процессы для удовлетворения требований клиентов. Однако способность изменять встроенные процессы и их логику ограничена и доступна только через предопределенные шаблоны или конфигурации (рис. 1).
Рис. 1. Традиционное приложение, имеющее монолитную структуру
При этом имеются существенные выгоды от обеспечения более полных функциональных возможностей для встроенных в приложения процессов, но эта монолитность мешает приложениям приспосабливаться к уникальным потребностям различных клиентов. Можно сравнить монолитное приложение с бетонным строением, которое невозможно перестроить без разрушения. Строение, созданное из крупных компонентов, в случае необходимости легко изменить, используя существующие материалы и докупив новые блоки - сервисы. Если требования клиента обеспечиваются функциональностью встроенных в монолитное приложение процессов, то оно работает хорошо. Однако если требования клиента не могут быть выполнены из-за недостаточной гибкости приложения, то единственным решением может стать изменение приложения, что существенно в плане стоимости внедрения и дальнейшей поддержки. В противном случае пользователь вынужден работать в соответствии с правилами встроенных в приложение процессов и отказаться от использования тех процессов, которые ему на самом деле нужны. Оба варианта не добавляют эффективности предприятию, и в данном случае на одной чаше весов находится полнофункциональное приложение с большой стоимостью владения, которое сложно изменять, а на другой - типовое приложение, вынуждающее пользователя работать в соответствии с заложенными в нем типовыми процессами. Также важно и то, что встроенные в приложение бизнес-процессы ограничены по функциональности и не могут быть легко расширены, чтобы применять сервисы, предоставляемые приложениями других разработчиков.
Service Oriented Architecture
SOA изменяет данную ситуацию, позволяя приложениям определить все свои основные сервисы как дискретные функции - "кирпичики". Следствием этого является тот факт, что процессы, которые применяют данные сервисы, могут быть автоматизированы с использованием набора существующих сервисов, как показано на рис. 2. В таком случае они легко настраиваются или перестраиваются для удовлетворения уникальных потребностей каждого клиента. Кроме того, эти процессы могут быть легко и быстро изменены в ответ на изменение внешней среды.
Рис. 2. Приложение, построенное на базе SOA
Однако следует понимать, что нацеленность на максимальное удовлетворение специфических требований клиента может помешать типизации самих сервисов, то есть схожие по функциональности сервисы не будут типизированы, что отрицательно скажется на стоимости и времени изменения системы. В данном случае наиболее эффективно максимально типизировать сервисы, обеспечивая при этом свободу в плане организации логики выполнения процесса (workflow).
Сервисы в SOA доступны путем использования стандартного протокола, который является основой web-сервисов и становится стандартом для программного обеспечения. Применение web-сервисов в качестве средства интеграции в SOA означает, что приложения других разработчиков могут использовать данные сервисы без потребности в точечной интеграции, которая дорога и неустойчива. В данном случае web-сервис выступает в роли небольшого независимого приложения, которое предоставляет средства доступа к информации через набор существующих возможностей. Технология web-сервисов базируется на следующих открытых стандартах:
- XML - расширяемый язык разметки, предназначенный для хранения и передачи структурированных данных;
- SOAP - протокол обмена сообщениями на базе XML;
- WSDL - язык описания внешних интерфейсов web-сервисов на базе XML;
- UDDI - универсальный интерфейс распознавания, описания и интеграции (Universal Discovery, Description and Integration), позволяющий создавать каталоги web-сервисов, предоставляющих их во всеобщее пользование.
Web-сервисы базируются на языке XML, что означает независимость от платформы. А благодаря тому, что web-сервисы основаны на открытых стандартах и протоколах, достигается простота их разработки и отладки. Наконец, web-сервисы обеспечивают свободное взаимодействие между поставщиком и потребителем. Это означает, что когда сервис изменяется вследствие применения новой версии, замены приложения или изменения платформы, то использующее данный сервис приложение менять не нужно.
С появлением сервисов, применяющих стандартные протоколы, места хранения и принципы вызова, роль BPM-систем становится в SOA центральной. Поскольку организации имеют иерархию взаимосвязанных процессов, то процессы, лучше всего организованные в монолитных приложениях, там же и остаются. Однако поддержка новых процессов может быть осуществлена вне монолитных приложений, что обеспечивает "сквозную" автоматизацию, которая была бы невозможна в пределах одного монолитного приложения (рис. 3).
Рис. 3. "Сквозная" автоматизация
"Сквозная" автоматизация важна, потому что сегодня почти во всех случаях предприятию требуется ИТ-решение, состоящее из нескольких приложений. В дополнение к этому во многих бизнес-процессах обычно участвует множество людей, что важно для быстрого принятия решения, обработки исключений и "человеческого контакта", который отличает процессы, ориентированные на исполнителей, от процессов, ориентированных на данные, где приемлема более жесткая автоматизация. При этом на предприятиях за время их существования накопилось множество разнородных приложений, не всегда связанных между собой. В этом хаосе иногда очень трудно разобраться, и помочь в такой ситуации может только SOA. При использовании SOA cервисы становятся элементами проектирования, и самое главное - это правильно их выделить (выделение сервисов наиболее эффективно при процессном подходе). Таким образом, можно будет говорить о переходе от архитектуры приложений, основанной на интеграции, к сервис-ориентированной архитектуре, базирующейся на бизнес-процессах.
Business Process Management
Любая организация использует много процессов, для повышения эффективности которых необходимо обеспечить их "сквозную" автоматизацию. Управление такими процессами требует применения специализированной системы Business Process Management (BPM), которая позволяет управлять процессами в течение всего их жизненного цикла. Системы BPM - это совокупность приложений и систем класса middleware, поддерживающих специализированные задачи управления "сквозными" процессами (моделирование, внедрение, оперативное управление и администрирование, мониторинг и анализ показателей эффективности), а также взаимодействие людей и информационных систем.
BPM обеспечивает адаптивность и поддержку SOA и фактически является центральной нервной системой в архитектуре, потому что управляет вызовом сервисов, предоставленных различными приложениями. Теперь процессы уже не встроены в монолитные приложения, где их сложно изменять. При использовании BPM и SOA процессы существуют вне монолитных приложений и могут быть просто изменены в соответствии с потребностями клиента. "Сквозные" процессы, автоматизированные в BPM-системах, могут объединять в единое целое процессы в монолитных системах и создавать их "сквозную" автоматизацию. Большинство BPM-систем позволяет организовать управление процессами намного легче и дешевле по сравнению с монолитными системами. В дополнение к этому средства внесения изменений в процессы, управляемые BPM-системами, позволяют осуществлять эти изменения максимально быстро и с минимальными затратами.
Можно предположить, что роль BPM-систем является центральной для проектирования SOA, и правильно говорить о создании процессно-ориентированной архитектуры (Process Oriented Architecture, POA). В связи с этим следует отметить, что понятия "сервис" и "процесс" взаимозависимы и могут применяться на разных уровнях обобщения. Небольшой процесс может быть организован в качестве сервиса в случае возможности его типизации, но в то же время сервис может быть разбит на подсервисы, взаимодействующие в рамках процесса, если типизация на данном уровне недопустима. Сервисы существуют для того, чтобы быть использованными в процессах, и все больше сервисов будет создаваться централизованно для применения множеством компаний. В этом случае ключевые преимущества будут достигаться за счет совершенствования внутренних бизнес-процессов предприятия.
Ultimus BPM Suite и SOA
Поддержка SOA и web-сервисов является стандартной функциональностью системы Ultimus Adaptive BPM Suite. Она предоставляет полномасштабную интеграцию с использованием web-сервисов как их поставщика, так и их потребителя с помощью следующих компонентов:
- web-сервис Flobot - это так называемый workflow robot, который может быть включен в графическое описание процесса в качестве отдельного шага для вызова web-сервиса или выполнения операций по обмену данными между процессом и web-сервисом;
- web-сервис Event Conditions - этот сервис может быть вызван всякий раз, когда в процессе на любом шаге происходят события, используемые для управления потоком работ. Это позволяет вызывать web-сервис для случаев, описанных в виде правил и зависящих от следующих событий процесса: окончание шага, шаг просрочен, шаг возвращен и т.д.;
- web-сервис Form Event - данный сервис может быть вызван при наступлении какого-либо события из пользовательской формы Ultimus, что позволяет создавать многофункциональные пользовательские интерфейсы, которые напрямую взаимодействуют с другими приложениями, находящимися в среде SOA;
- web-сервис Step Completion - любой шаг в процессе Ultimus может быть закончен и данные могут быть переданы из web-сервиса в автоматизируемый процесс, что является примером того, как приложения сторонних разработчиков могут использовать web-сервисы, представленные Ultimus, а также передавать информацию в процесс Ultimus;
- web-сервис Process Initiation - приложения других разработчиков могут сгенерировать новый инцидент процесса Ultimus, вызывая специфический web-сервис, что позволяет этим приложениям начать инциденты процесса, передавая им требуемые данные из приложения;
- web-сервис Reporting - этот web-сервис позволяет приложениям других разработчиков извлекать данные о бизнес-процессах и данные процесса из Ultimus BPM Suite, что дает этим приложениям возможность осуществлять бизнес-анализ, контроллинг процессов и отчетность для управления и оптимизации процессов.
Используя данные возможности, можно развернуть бизнес-процессы с помощью архитектуры SOA, а в качестве инструмента применять Ultimus BPM Suite (рис. 4). Кроме того, "сквозные" процессы могут охватить множество приложений, используемых на предприятии, что является существенным фактором успешного внедрения процессного управления.
Рис. 4. Ultimus Adaptive BPM Suite в качестве основы SOA
Заключение
С появлением концепции SOA и в результате ее активного обсуждения вновь актуальной стала проблема эффективности использования информационных технологий, а кроме того, повысился интерес к бизнес-процессам и системам класса BPM как инструментам автоматизации процессов. Однако при построении ИТ-архитектуры на основе SOA сложность заключается не только в типизации сервисов, но и в изменении подходов к управлению организацией с функционально-ориентированных на процессно-ориентированные, что требует изменения управленческой культуры в компании.
Взаимосвязь между SOA и BPM настолько сильна, что SOA без BPM не может быть реализована, тогда как BPM без SOA прекрасно существует. Но чем выше степень автоматизации бизнеса и разнообразнее задачи, тем сильнее становится необходимость в SOA по причине сложности ИТ-инфраструктуры и проблем, связанных с поддержкой. Взаимное пересечение BPM и SOA требует успешного развития обоих направлений, и многие аналитики сходятся во мнении, что успех SOA зависит главным образом от правильного управления бизнес-процессами.
В настоящее время многие BPM-системы, в том числе Ultimus Adaptive BPM Suite, могут предоставить набор инструментов, которые позволят начать применять принципы SOA на практике.
По прогнозу аналитической компании Gartner, к 2008 году более 60% предприятий будут использовать SOA в качестве основного принципа построения корпоративной ИТ-архитектуры.