Архитектура сервисов предприятия в SAP NetWeaver

--> Дата: Фев 18, 2008 498

Владимир Гарусов, Игорь Иваненко,
«SAP СНГ и страны Балтии»

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

Реакцией на эти требования стало появление концепции распределенной сервисно-ориентированной архитектуры ПО (service-oriented architecture, SOA) на базе Web-сервисов. В отличие от используемых до сего времени схем "жестких" соединений для организации взаимодействия приложений, SOA позволяет оперативно реагировать на изменение ситуации, оптимизируя использование базовых конструктивных блоков.

Учитывая эти тенденции современного ИТ-рынка, компания SAP (http://www.sap.com/cis)
разработала собственный концептуальный проект ESA (enterprise service architecture
– архитектура сервисов предприятия) на базе идей SOA. В январе 2003 г. на рынке
была представлена практическая реализация ESA – SAP NetWeaver.

SAP NetWeaver – это платформа нового поколения на базе сервисов, которая будет служить основой для всех будущих приложений SAP и уже сегодня выступает как мощное средство интеграции людей, процессов и данных с приложениями (SAP- и не-SAP-архитектур). Платформа включает несколько технологических и прикладных компонентов: среду разработки и функционирования приложений (SAP Web Application Server и SAP NetWeaver Developer Studio), инфраструктуру обмена (SAP XI), хранилище бизнес-информации (SAP BW), средство массового распространения информации (BI Information Broadcasting), портал предприятия (SAP EP), инфраструктуру для мобильных клиентов (SAP MI), средства управления знаниями (SAP KW) и управления основными данными (SAP MDM). Кроме того, SAP NetWeaver служит основой для создания составных приложений (SAP xApps), которые используют уже имеющийся в решениях функционал для реализации новых возможностей или расширения семейства продуктов SAP.

Открытость NetWeaver обеспечивается за счет поддержки соответствующих стандартов на всех уровнях интеграции (рис. 1). Продукт также отвечает потребностям клиентов в создании более однородной и локально доступной интегрированной среды для пользователей. Это означает переход от множества различных систем с множеством разных пользовательских интерфейсов к порталу, что дает любому пользователю доступ ко всей информации и приложениям из одной точки доступа посредством браузера.

Рис. 1. Обеспечение открытости SAP NetWeaver.

Типы Web-сервисов

Технология Web Services активно обсуждается ИТ-специалистами уже более трех лет. И если с ответом на вопрос "Что такое Web-сервисы?" практически все разобрались, то с другими – например, "Что я могу делать с Web-сервисами?", "В каких случаях они необходимы?" – полного понимания пока нет. Чтобы ответить на эти вопросы, сначала нужно разобраться, какие типы сервисов существуют в ESA, как эти сервисы соотносятся с существующими интерфейсами приложений и что это означает в контексте создания новой модели взаимодействия с пользователями.

Web-сервисы – это стандартизованный способ объединения приложений, работающих
на базе Web-технологий, за счет использования открытых стандартов XML, SOAP,
WSDL и UDDI в качестве Интернет-протоколов. Для нас важно, что Web-сервисы предоставляют
интерфейс, который описан и который можно вызвать стандартным образом. В архитектуре
ESA предполагается, что все коммуникации между компонентами базируются на Web-сервисах
различных видов (рис. 2).

Рис. 2. ESA базируется на системе Web-сервисов.

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

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

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

Следующие примеры подробнее поясняют различие между традиционным подходом и технологией Web-сервисов.

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

Пример: в системе SAP в течение долгого времени существовал интерфейс,
чтобы импортировать рейтинги кредитоспособности из базы компании Dun & Bradstreet.

Web-сервисы. С их появлением все коммуникации осуществляются по стандартным
протоколам. Средства разработки для любого сервиса – это очень простые в использовании
современные инструменты разработки. К Web-сервисам обычно обращаются по требованию,
поэтому нет необходимости тиражировать данные. Во многих случаях распространение
Web-сервисов приводит к естественной семантической стандартизации. Это происходит
потому, что несколько поставщиков используют одни и те же интерфейсы, или потому,
что появляются компании, которые обобщают сервисы от нескольких поставщиков
и предлагают унифицированный интерфейс. Если семантика интерфейсов идентична,
то выбор между поставщиками сервисов сводится просто к обращению к сервису от
другого поставщика (plug-and-play).

Пример: сейчас компания Dun & Bradstreet предлагает Web-сервис, который
по запросу выдает текущий рейтинг кредитоспособности для запрашиваемой компании.
Этот Web-сервис может вызываться любым приложением.

Сервисы предприятия основаны на технологии Web-сервисов и, таким образом,
используют все разработки в этой области. Однако сервисы предприятия создаются
для использования в пределах или вне предприятия. Это означает, что они базируются
на объектной модели предприятия и реализуют его бизнес-правила.

Пример: предприятию не нужен доступ к рейтингам кредитоспособности потенциальных
клиентов, но ему требуется реализовать сервис предприятия, который отвечает
на вопрос: "Должен ли я принять заказ со стоимостью X и условиями платежа Y
от клиента Z?". Чтобы ответить на этот вопрос, соответствующий сервис предприятия
может объединять информацию от Dun & Bradstreet с информацией от приложения
"Управление дебиторами" и использовать специфический для предприятия алгоритм,
чтобы определить, принять заказ или нет. Этот сервис предприятия может вызываться
любым используемым на предприятии приложением для ввода заказа на поставку.
Подчеркнем, что при этом все коммуникации базируются на технологии Web-сервисов.

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

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

Учитывая, что интегрировать придется независимо спроектированные приложения, критерии для определения и проектирования сервисов можно уточнить следующим образом.

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

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

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

Взаимодействие с пользователями

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

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

В-третьих, современные технологии взаимодействия с пользователями, такие, как SAP WebDynpro, полностью поддерживают среду визуальной разработки компонентов на основе сервисов. Сервисы можно найти в таблице регистрации, а модули доступа (proxy) будут сгенерированы автоматически. Сервисы возможно организовать в соответствии с требуемой моделью взаимодействия. Окончательный компонент взаимодействия с пользователями генерируется для различных сред исполнения, вновь предоставляя возможность выбора соответствующей технологии.

Преимущества ESA/SOA для заказчика

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

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

Осуществить все это и позволяет ESA как методология и SAP NetWeaver как инструмент.

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

С внедрением SAP NetWeaver можно использовать функциональность старых приложений и увеличить их действительную стоимость, поместив над ними единый, однородный интеграционный слой, который понимает "чужие" приложения, может использовать их основные функции и соединять разрозненные данные в единые и однородные информационные каналы в компании.

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

Что дает компаниям SAP NetWeaver

Существует несколько стимулов, мотивирующих компании переходить на концепцию ESA:

быстро изменяющаяся бизнес-среда, в которой конкурентоспособными оказываются гибкие и динамично развивающиеся компании;
инициативы, ориентированные на расширение взаимодействия с клиентами/поставщиками;
сокращение ИТ-бюджетов, в результате которого выросла потребность в краткосрочных проектах развертывания интегрированной ИТ-архитектуры с более быстрым возвратом инвестиций;
потребность в уменьшении TCO существующих и новых систем по всей компании;
появление открытых стандартов – в частности, более реалистичного (по сравнению с EDI-стандартами) набора стандартов, основанных на XML.

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

Для решения задач интеграции требуется однородный связующий слой ПО над всеми вспомогательными приложениями. Казалось бы, реальная потребность в таком слое не очень велика, так как все промежуточное ПО, даже новые решения SOA (например, от Microsoft, IBM и SAP), имеет возможность взаимодействия с другими решениями. Но это не так.

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

Конечно, в некоторых компаниях уже имеются хранилища данных, решения для управления знаниями и промежуточное ПО. Не всегда имеет смысл внедрять все это заново. Вот почему SAP NetWeaver специально разрабатывался для простой интеграции с другим промежуточным ПО, другими хранилищами данных, продуктами KM и даже с другими порталами.

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

Как выбрать нужные компоненты SAP NetWeaver

Методология компании SAP основана на оценке, понимании и определении окончательных целей компании и создании маршрутной карты (плана) достижения этих целей. Прежде всего нужно ответить на вопрос: "Какие элементы существующей ИТ-архитектуры стратегически релевантны при внедрении SAP NetWeaver?".

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

затраты на приобретение лицензий;
возможность повторного использования существующих сервисов;
возможность упростить процесс интеграции SAP NetWeaver с промежуточным ПО и системами, которые интегрированы в промежуточном ПО (может быть, некоторые специфические адаптеры пока не доступны в XI);
предполагаемый срок службы систем, связанных с этим промежуточным ПО.

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

Вряд ли при внедрении NetWeaver следует заменять существующие хранилища данных. Важное требование к используемым хранилищам данных состоит в том, чтобы данные имели стандартный вид, облегчающий использование OLAP-инструментов. Более старые продукты не всегда соответствуют этим стандартам, поэтому их следует заменить на SAP BW из NetWeaver. Стандартный подход – использование существующих хранилищ данных путем размещения их отчетов/запросов на порталах NetWeaver или для того, чтобы "питать" данными из этих хранилищ стратегические инфокубы SAP BW. То же самое относится и к инструментам управления знаниями.

Результатом оценки будет понимание того, какие части существующей (или внедряемой) архитектуры останутся в среде NetWeaver, т. е. могут сочетаться с методологией ESA.

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

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

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

Как использовать NetWeaver для реализации стратегической архитектуры

Один из важных факторов в определении места NetWeaver – нужно иметь представление о стратегической ИТ-архитектуре компании. Понятно, что многие предприятия уже имеют ИТ-инфраструктуру на определенной стадии развития. Она может быть развитой, со множеством компонентов SOA, или находиться в зачаточном состоянии. Другие компании еще не вполне определились со своей ИТ-стратегией.

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

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

В качестве первых шагов нужно ответить на следующие вопросы:

есть ли в компании стратегическая ИТ-архитектура;
как SAP NetWeaver вписывается в эту стратегическую ИТ-архитектуру;
должен ли он заменить существующую архитектуру или работать параллельно с ней.

Что дает NetWeaver по сравнению с имеющейся архитектурой

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

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

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

Например, возможны такие варианты: внедрить в отдельной бизнес-группе решение mySAP ERP на платформе NetWeaver (например, путем переноса существующей системы SAP R/3) или использовать XI, чтобы интегрировать приложения и создать В2В/В2С-интерфейсы так, чтобы их можно было использовать как часть стратегической ИТ-архитектуры.

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

Как перейти от имеющейся архитектуры на NetWeaver

Клиенту, который собирается использовать NetWeaver, нужен план – "маршрутная карта", которая определит, как перейти от существующей архитектуры к конечной стратегической ИТ-архитектуре. Анализ, необходимый для построения такого плана "с нуля", – задача достаточно сложная и ресурсоемкая. Но для этого можно использовать общие подходы к решению данной проблемы. Для начала нужно ответить на следующие ключевые вопросы.

Как это затронет работу со стратегическими партнерами? Будут ли затронуты инициативы, связанные со взаимодействием с клиентами/поставщиками?
Каким образом создание стратегической архитектуры будет способствовать достижению бизнес-целей? Есть ли краткосрочные цели, которые должны быть достигнуты в первую очередь?
Нужно ли пересмотреть или, возможно, изменить направление текущих проектов?
Что нужно сделать, прежде чем планировать внедрение NetWeaver? Например, необходима ли единая кодировка, "очистка" данных, рационализация систем?

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

"Маршрутная карта" должна состоять из серии краткосрочных тактических решений, каждое из которых предоставляет компоновочные блоки для создания итоговой архитектуры. Необходимо тщательно обдумать и понять влияние каждой стадии "маршрутной карты": например, каким образом портал SAP NetWeaver будет взаимодействовать с существующим порталом. Для каждой из существующих систем должен быть определен детальный путь и позиция на каждой стадии "маршрутной карты". Это касается существующих (SAP и не-SAP) приложений, порталов, инструментов для управления знаниями, хранилищ данных и т. д.

Компания SAP обладает необходимой методологией, чтобы помочь в создании "маршрутной карты", и может предоставить промежуточные решения, которые легко адаптируются к окончательным стратегическим решениям конкретной компании. Отправной точкой в создании "маршрутной карты" для компании может служить карта решения SAP NetWeaver (рис. 3).

Рис. 3. Карта решений SAP NetWeaver.

Как с помощью NetWeaver перейти к SOA

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

Если рассматривать решения IBM (набор инструментов WebSphere), Microsoft (.NET) и SAP (NetWeaver), анализ покажет, что эти решения похожи по концепции и в той или иной степени ориентированы на предоставление полной архитектуры SOA. Так в чем же различие между ними? Каждый продукт имеет свои преимущества и свои недостатки, и, только оценив каждый конкретный случай, можно выбрать наиболее подходящий инструмент. Самый простой, лежащий на поверхности критерий – в какой степени приложения данного поставщика уже применяются в компании.

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

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