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

Учитывая серьезность проблемы интеграции корпоративных ИТ-систем, можно понять интерес к ней «капитанов» отрасли. Например, компания SAP предлагает собственную методику бесшовной интеграции приложений, а также, что не менее важно, возможность централизованного управления данными, унаследованными из различных систем. Разработчики интеграционной платформы NetWeaver сравнивают ее создание с появлением в начале 90-х годов трехзвенных клиент-серверных архитектур, значительно способствовавших успеху R/3. Действительно, платформа NetWeaver создавалась с опорой на концепцию архитектуры корпоративных сервисов (Enterprise Services Architecture — ESA), в соответствии с которой будут теперь проектироваться все программные решения немецкого концерна.

Enterprise Services Architecture

Впервые представленная летом 2003 года, архитектура ESA (рис. 1) не является описанием какой-либо определенной, единственно правильной методики построения корпоративной ИТ-системы. Скорее, это перечень вопросов, которые возникают у проектировщиков, и своего рода шаблоны, помогающие сформировать правильные ответы на них с учетом индивидуальных требований и современных стандартов [1]. Некоторая размытость определения характерна и для описания архитектур, ориентированных на сервисы [2], что, впрочем, не мешает Service Oriented Architecture (SOA) претендовать на роль ведущей концепции интеграции приложений.

Рис. 1. Архитектура ESA

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

Для решения этой проблемы ESA предлагает принцип более свободного соединения системных модулей посредством сервисов — описаний специфических интерфейсов компонентов системы. Благодаря таким открытым интерфейсам пользователь может работать с функциями того или иного приложения, не зная, откуда берутся данные и какие системы применялись для их обработки. Чтобы реализовать связи компонентов с помощью сервисов, не нужно переписывать все программные модули заново. Для поддержки сервисов подойдут и системы, написанные на ABAP (язык программирования, разработанный SAP), но клиентские расширения модулей SAP могут быть написаны и на Java.

В основе Enterprise Services Architecture — стремление обеспечить соответствие бизнес-стандартам всех работающих на предприятии систем. При этом объединяемые в рамках концепции ESA составляющие взаимодействуют на всех уровнях интеграции: это людские ресурсы, бизнес-процессы, управленческая информация. Авторы концепции убеждены, что, придерживаясь ESA, разработчики создадут лучшие условия для масштабирования системы, повышения отказоустойчивости, безопасности и управляемости ИТ-среды.

Реализация архитектуры ESA предполагает изменение подхода разработчиков к созданию приложений, а также манеры их использования корпоративными пользователями. По сути, ESA является применением ориентированной на сервисы архитектуры и принципов объектно-ориентированной разработки приложений к современным гетерогенным ИТ-структурам.

Платформа NetWeaver

В конце 2001 года стратегическое для SAP направление обозначила платформа mySAP, объединившая компоненты Portal и Exchange Infrastructure для интеграции человеческих ресурсов и бизнес-процессов. В 2002 она была усилена модулем xApps, а в 2003 — компания представила NetWeaver, техническое воплощение идеи архитектуры корпоративных сервисов.

SAP NetWeaver — платформа для интеграции приложений и информации, поддерживающая среды разработки Microsoft .Net и J2EE, в частности IBM WebSphere. Платформа предлагает средства интеграции не только для «своих» продуктов и включает в себя следующие компоненты: Enterprise Portal, Mobile Infrastructure, Business Intelligence, Master Data Management, Exchange Infrastructure, Web Application Server. Каждый из модулей может функционировать независимо, но разработчики подчеркивают, что максимальный эффект достигается при их взаимодействии. Все компоненты NetWeaver работают на одном сервере приложений — поставщике Web-сервисов, поддерживающем стандарты XML, SOAP, WSDL и UDDI. Для пользователей может быть создана единая точка доступа во все системы на ролевой основе.

NetWeaver позволяет в рамках одной платформы собрать различные решения SAP для построения корпоративной системы изо всех доступных активов. Посмотрим, как идея интеграции реализуется на разных уровнях: люди, информация и бизнес-процессы (рис. 2).

Рис. 2. Структура платформы SAP NetWeaver

Интеграция человеческих ресурсов

Верхний уровень логической конструкции NetWeaver представляет собой блоки, обеспечивающие консолидацию человеческих ресурсов. Все пользователи — «мобильные» и «стационарные», сотрудники всех отделов и корпоративное руководство — должны быть вооружены не только инструментами для выполнения задач в соответствии со своими должностью и функциями, но и средствами для коллективной работы. Эти возможности в NetWeaver поддерживаются на основе многоканальных коммуникаций и платформонезависимого портала.

За обеспечение многоканальных коммуникаций отвечает SAP MI (Mobile Infrastructure) — среда для мобильных решений, позволяющая сотрудникам компании осуществлять удаленный доступ к бизнес-значимым приложениям. SAP MI допускает работу с мобильными решениями как в подключенном (оn-line), так и в автономном (оff-line) режиме. Доступ к сервисам в SAP MI поддерживается для мобильных устройств самых разных типов — карманные компьютеры, RFID-ярлыки и др. В качестве клиентов может использоваться браузер или отдельное приложение. SAP MI, базируясь на стандартах Java и XML, позволяет синхронизировать данные на мобильных устройствах и корпоративном сервере. При этом все мобильные компоненты инфраструктуры управляются с центральной консоли администратора.

Другим инструментом, работающим для объединения человеческих ресурсов (и, пожалуй, самым важным компонентом NetWeaver), является корпоративный портал SAP EP (Enterprise Portal). Он служит единой точкой доступа к разнородной информации, приложениям, сервисам.

Портал организован по ролевому принципу. Имеется портал для клиентов, на котором хранится информация о продуктах и услугах. Есть специальный портал руководителя, предоставляющий ему данные о персонале, финансах, стратегии компании и аналитические сведения. Портал сотрудника дает пользователям доступ к mySAP Business Suite и приложениям сторонних поставщиков. Важной функцией является режим Single Sign-On, допускающий однократную регистрацию пользователей на портале для обращения к различным системам. В дальнейшем регистрация в запрашиваемых приложениях будет выполняться автоматически.

Информация из разных систем, в том числе принадлежащих сторонним поставщикам, содержимое баз данных, неструктурированные документы и Web-контент доставляются сотрудникам через Enterprise Portal, предлагающий соответствующие инструменты для коллективной работы. Различные системы могут интегрироваться в портал с помощью так называемых бизнес-пакетов и соответствующих программных «мастеров».

Бизнес-пакет представляет собой комплект «наборов», поддерживающих работу с определенными функциями конкретного приложения. Скажем, для интеграции в портал модуля SAP SEM в пакет Strategic Enterprise Management включены набор Стратегический менеджмент, открывающий доступ к функциям карты сбалансированных показателей, набор Консолидация для представления информации о процессе консолидации и набор Измерение производительности, обеспечивающий графическое отображение показателей деятельности предприятия.

Чтобы упростить процесс создания портального содержимого, в SAP EP можно воспользоваться набором шаблонов. На основе подобных «домашних заготовок» с помощью мастеров без программирования создаются нужные формы. Специальный инструмент SAP Visual Composer позволяет считывать бизнес-объекты из связных систем и путем простого перетаскивания графических элементов строить нужные комбинации. Если Visual Composer адресован в основном пользователям, то для более серьезных разработок можно взять на вооружение построенный на базе Eclipse набор инструментов для дизайна приложений SAP NetWeaver Development Studio. Для таких задач в «Студии» сначала посредством графических инструментов описывается модель приложения, а затем автоматически генерируется Java-код.

В ракурсе интеграции людских ресурсов предприятия особый интерес представляет функциональность Real-time Collaboration. Поддерживаются функции совместной работы с приложениями, обмен сообщениями, работа с контактами в портале и чат. По сути, данный элемент представляет собой виртуальное пространство для поддержки рабочих групп. При этом каждый пользователь может создать собственную «комнату сотрудничества» для ведения групповых проектов, дискуссий, совместной работы с документами, координирования встреч. Для удобства предусмотрены мастер создания «комнат» и подборка шаблонов. В «комнату сотрудничества» допускается интегрировать другие компоненты, в том числе третьих фирм (например, WebEx, Microsoft Exchange, Lotus Notes).

Интеграция информации

На уровне интеграции информации работает один из элементов SAP Enterprise Portal — интегрированная платформа управления знаниями, позволяющая организовать доступ пользователей к неструктурированной информации. Для этого применяются методики публикаций и подписки, а также обычное представление через браузер.

Разработчики SAP отказались от объединения всей доступной информации в пределах одного хранилища. Вместо этого через модуль Knowledge Management реализуется единая точка доступа к данным, связанная репозиториями посредством контент-менеджеров. Система управления знаниями располагает и собственным хранилищем документов, что бывает полезно при небольших объемах информации. SAP Enterprise Portal КМ обеспечивает унифицированный доступ, управление, классификацию и предоставляет общий набор сервисов для разнородных хранилищ неструктурированной информации. На данный момент реализованы менеджеры репозиториев для Windows, WebDAV-совместимых серверов: Microsoft Sharepoint, Exchange Public Folders и LiveLink. Возможно взаимодействие с Lotus Notes, mySAP PLM DMS, SAP Knowledge Warehouse и другими системами управления документами.

Одним из центральных компонентов платформы, который, как полагают в SAP, востребован и в России, является инструментарий корпоративной аналитики SAP Business Intelligence. Он позволяет создавать хранилища данных и управлять ими, обеспечивает обработку больших объемов информации в пределах хранилища, поддерживает как стандартную форматированную отчетность, так и различные аналитические инструменты — OLAP, раскопка данных, бизнес-планирование и моделирование. Как и в случае с порталом, сотрудник получает информацию в том виде, который ему удобен и положен по статусу (менеджер, аналитик, бухгалтер, администратор и т.д.); для каждого организуется оптимизированная рабочая среда. При необходимости с помощью пакета разработчика BI Java SDK можно создать собственные расширения для SAP BI.

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

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

SAP Master Data Management

Самый «молодой» компонент платформы NetWeaver — SAP Master Data Management — должен помочь в решении проблемы консолидации, гармонизации и управления общими и специфическими отраслевыми объектами в гетерогенных ИТ-средах. Говоря о сохранности инвестиций в ИТ, о сокращении совокупной стоимости владения, в случае с NetWeaver следует выделить именно методику работы с информацией.

Философия данного компонента состоит в отказе от необходимости обслуживания данных в разных системах. Выигрыш, в первую очередь, должен ощущаться в скорости работы: в модуле предусмотрены механизмы распределения данных по соответствующим приложениям, причем обеспечиваются полнота представления и точность наборов данных. Таким образом, по утверждению разработчиков, сокращаются расходы на устранение возможных ошибок, возникающих из-за неоднородности данных.

Рис. 3. Работа с данными в SAP Master Data Management

Весь цикл работы SAP MDM (рис. 3) можно поделить на три этапа. Во-первых, проводится консолидация мастер-данных (справочников), которые состоят из двух частей — метаданные и собственно «смысловые» данные. Формат их представления зависит от СУБД, и они идентифицируются системой на основе информации из репозитария — словаря данных. Справочники изо всех систем загружаются в SAP MDM, и выполняется анализ объектов основных данных — продуктов, партнеров, основных средств и др. Потом система выявляет идентичные или схожие объекты.

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

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

Основное различие между глобальными и локальными данными заключается в порядке их администрирования. Глобальные данные могут копироваться в какие угодно системы, но управление ими осуществляется исключительно в MDM. В то же время на уровне приложений пользователь управляет локальными данными. Вопрос состоит в том, что целесообразно выносить на более высокий уровень, а что нет. Скажем, если поставщик имеет филиалы по всем городам и весям, торгующие одними и теми же товарами, то всю номенклатуру логично вести как глобальные данные. А вот цены и количества — разные по регионам — можно и нужно оставить в локальных системах.

Логически связанные между собой объекты могут распределяться и изменяться целой группой. Это очень полезно при работе с определенным продуктом: в едином контексте будут представлены данные спецификации, графики поставки или, скажем, маркетинговая информация.

Для гармонизации данных в MDM предусмотрен ряд функций.

  • Группировка по коммерческим признакам. Система устанавливает, какие объекты могут быть связаны с точки зрения бизнеса, определяет время и объем рассылки релевантных данных в соответствии с жизненным циклом бизнес-объекта.
  • Клиент-ориентированное управление данными. В определенных условиях управление данными на локальном уровне предпочтительнее: отдельные системы получают только необходимую информацию в определенное время. Для этого в локальной системе нужно разложить объект на части и поставлять клиенту требуемую порцию информации.
  • Синхронная проверка дубликатов. В процессе ревизии основных данных система должна производить поиск дубликатов так, чтобы не мешать работе тех приложений, для которых время критично.
  • Автоматическая доставка контента. Повышению эффективности работы в определенных условиях способствует режим автоматического распределения данных. Оно осуществляется по принципу событий: приложения-клиенты на основании бизнес-контента указывают события, которые инициируют рассылку данных.

Последним этапом организации работы с данными в рамках SAP MDM является создание механизма централизованного управления информационным потоком. Если управление атрибутами объектов в локальных системах не может удовлетворить всем выдвигаемым требованиям, то управление полным набором определений объекта, включая объектные зависимости, поручается центральному серверу основных данных. В таком случае обслуживание локальных систем допускается проводить намного реже.

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

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

В структуре модуля центральное место отведено серверу мастер-данных Master Data Server, который предоставляет весь комплекс сервисов консолидации, гармонизации и распределения таких данных в корпоративной среде. Функции сервера реализуются на трех уровнях (рис.4).

  • Уровень объектов. Объекты основных данных описываются и передаются в Контент-интегратор и инфраструктуру обмена. На этом слое конструкции создаются общие типы объектов основных данных, которые могут быть расширены и дополнены для использования в соответствующих приложениях.
  • Уровень сервисов. Здесь реализованы сервисы для управления основными данными и, среди прочего, функции создания объекта, управления изменениями и статусом, запросы, инструменты авторизации и др. При необходимости эти функции могут предоставляться в виде Web-сервисов.
  • Уровень распределения. На нем осуществляется управление распределением основных данных. Клиентам могут посылаться как отдельные объекты, так и объекты, составленные по прописанным на сервере правилам из группы элементов. В правильной адресации объектов на локальные системы помогают механизмы публикации и подписки, предусмотренные в модуле SAP Exchange Infrastructure.

Интеграция процессов

Фундамент для интеграции приложений в структуре NetWeaver формирует SAP Exchange Infrastructure (XI). Она включает в себя брокер интеграции, обеспечивающий обмен сообщениями между системами, и машину бизнес-процессов Business Process Engine, поддерживающую выполнение логики бизнес-процессов между информационными системами.

В центре SAP Exchange Infrastructure находится сервер интеграции Integration Server, который отвечает за движение XML-сообщений между всеми корпоративными системами в гетерогенной ИТ-среде. Он определяет адресатов (логическая и техническая маршрутизация) и выполняет процедуры отображения. Сервер интеграции связывается с другими системами посредством адаптеров.

В соответствии с концепцией, на стадии разработки все необходимые интерфейсы создаются независимыми от платформы и доступными посредством WSDL-описания. На начальной стадии данные сохраняются в специальном репозитории Integration Repository. Впоследствии, во время конфигурирования, из него можно выбирать компоненты и интерфейсы, необходимые для имеющегося системного ландшафта, и объединять их семантическими связями. Такая конфигурация сохраняется в отдельном каталоге Integration Directory.

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

В версии SAP XI 3.0 обеспечена расширенная поддержка B2B-сценариев, а также интегрированное управление бизнес-процессами. Предусмотрены средства для создания новых бизнес-сценариев путем определения и изменения всей значимой для интеграционных процессов информации. В NetWeaver правила управления процессами описываются с помощью стандартов X-Path и Business Process Execution Language for Web Services (BPEL4WS).

Шаг к свободе

Платформа NetWeaver была задумана как шаг прочь от монолитных ERP-приложений в сторону более свободных конфигураций, способных быстро адаптироваться к изменяющимся условиям. Реализующая концепцию Enterprise Services Architecture технология NetWeaver призвана обеспечить интеграцию как систем SAP, так и унаследованных решений сторонних производителей.

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

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

Литература
  1. Dan Woods, Enterprise Services Architecture. O?Reily & Associates, 2003.
  2. Леонид Черняк, SOA — шаг за горизонт. «Открытые системы», 2003, № 9.

Бархатная эволюция

Концепция сервисной шины предприятия (Enterprise Service Bus, ESB) уже не воспринимается как что-то периферийное или временное. По мнению аналитиков таких авторитетных компаний, как Gartner, IDC или META Group, ориентированные на сервисы архитектуры становятся стратегическим направлением развития ИТ-индустрии. По некоторым оценкам, за несколько лет объем рынка подобных систем может увеличиться до 8-10 млрд долл. Кроме того, такие архитектуры становятся следующим после мэйнфреймов и клиент-серверных систем эволюционным витком в области ИТ. Акцент на слове «эволюционный» не случаен. SOA подразумевает развитие корпоративной ИТ-системы, но не взрывное, а постепенное, не предполагающее замены всех cуществующих компонентов информационной системы предприятия.

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