Дэвид С. Линтикем
Бывший CTO компаний Mercator Software и SAGA Software,
автор
книг «Enterprise Application Integration» и
«Next Generation Application Integration:
From Simple Information to Web Services».
С ним можно связаться по адресу: linthicum@att.net
С недавних пор мы наблюдаем конвергенцию двух миров — интеграции приложений (Enterprise Application Integration, EAI) и бизнес-аналитики (Business Intelligence, BI). Их сближение вполне закономерно. Технологии EAI развиваются в сторону перемещения информации между исходной и конечной системами в рамках поддержки бизнес-транзакций в реальном или квазиреальном времени. Системы BI служат для осмысления этой информации и применения ее при решении тактических и стратегических задач.
Актуальное
и историческое
За последние годы интеграция приложений — по крайней мере как концепция — проложила себе путь в большинство ИТ-отделов. Однако интересно, что приходила она туда, как правило, вслед за бизнес-аналитикой. Испытав на себе преимущества хранилищ и витрин данных как механизмов, улучшающих понимание бизнеса, многие компании захотели пойти дальше. Проблема состоит в том, что системы BI дают нам доступ к информации, используемой для принятия критически важных стратегических решений. Но это автоматически означает определенную задержку в подготовке такой аналитики. А для многих отраслей, как выяснилось, связано как минимум с серьезными проблемами. Если возраст данных, необходимых для определения текущего состояния бизнеса, составляет несколько месяцев, то это значительно снижает их ценность для организаций, работающих, например, в сфере торговли или производства, где нужно быть скорее проактивными, нежели реактивными.
Так как способы анализа исторической информации при помощи общепринятых аналитических инструментов хорошо известны, легко понять, чем был бы ценен аналогичный взгляд на информацию реального времени. Многие компании были заинтересованы в том, чтобы из процесса подготовки информации изъять фактор задержки во времени, что позволило бы им сравнивать старые и новые данные в общей аналитической архитектуре. Благодаря этому пользователи получили бы, например, возможность просматривать агрегированные продажи за последние три года наряду с теми, что происходят непосредственно в данный момент. Они смогли бы оценивать состояние бизнеса в контексте как текущих событий, так и исторических данных, корректируя его по ходу дела.
Скажем, предприятие розничной торговли, для которого важны тончайшие колебания маржинальных прибылей, получило бы возможность просматривать продажи во всех магазинах в реальном времени, по мере их совершения, и следить за значениями «точечных» показателей, таких как прибыльность каждого продукта. Удалось бы, кроме того, сопоставить нынешнее состояние с тем, которое наблюдалось в прошлом месяце, год назад или, может быть, в течение последнего десятилетия. Проводя подобный сравнительный анализ, бизнес-пользователи сумели бы определить, что желательно с точки зрения исторической перспективы и как это отразится на происходящем в бизнесе в данный момент.
Тут уже становится понятно, почему интеграция приложений в компаниях нередко приходила вслед за бизнес-аналитикой. Без интеграционной инфраструктуры концепция оперативной аналитики и управления бизнесом в реальном времени не будет работоспособна, так как мы просто-напросто не сможем получать данные из существующих информационных систем. Приняв, что аналитике реального времени нужно взаимодействовать с действующими информационными системами и что нам необходима историческая аналитика, мы должны будем согласиться и с тем, что EAI и BI неизбежно идут рука об руку. Тем самым развитие синергии между этими двумя технологиями предрешено.
Осмысление предметной области
Синергия между EAI и BI — вовсе не новость, по крайней мере на концептуальном уровне. Очень важно, чтобы актуальные и исторические данные сосуществовали в рамках одной и той же аналитической архитектуры. Их разделение обесценивает результаты и той и другой. Но как добиться синергии?
Здесь надо вспомнить, что интеграция приложений — вопрос не столько выбора между J2EE и .Net, сколько осмысления предметной области. Аналогичным образом обстоят дела и при объединении оперативной и исторической аналитики. Главное, что нужно, — это во всех подробностях понять, чем вы располагаете и как можно использовать то, что есть, для лучшего управления бизнесом.
Соответствующий процесс состоит из четырех шагов:
- определение источников информации;
- определение метаданных;
- разработка абстрактного представления бизнес-информации;
- разработка аналитики.
Как видим, здесь я опускаю создание инфраструктуры, хотя без этого, разумеется, тоже не обойтись.
- Для начала следует выяснить все детали, связанные с источниками информации
— как теми, которые вы полностью контролируете (скажем, с устаревшей системой,
от которой не удается отказаться, поскольку она всё ещё ценна), так и приложениями
внешних поставщиков, таких как системы SAP. Все они хранят и вырабатывают
информацию, и нужно понять, каким образом эта информация предоставляется для
внешнего использования и каково ее значение. Например, в случае SAP, где базы
данных практически невидимы извне, применяются специальные API. В каких-то
других системах наличествует иерархия, есть и такие, что генерируют XML или
даже дают прямой доступ к данным (что очень удобно, но, к сожалению, редко
встречается). Разобраться во всем этом многообразии, очевидно, очень и очень
непросто, но крайне необходимо.
- Разобравшись с системами-источниками, вы должны будете определить метаданные
и отобразить на общую логическую основу всю исходную информацию. Это необходимое
условие для третьего шага — создания абстрактного представления, — поскольку
нужно знать, что именно абстрагируется.
- При построении абстрактного представления информации вы, в сущности, приводите
ее физические представления в разных системах-источниках к единому унифицированному
виду, более удобному для аналитики. Помните, что эта процедура выполняется
для текущей (реального времени), оперативной (относящейся к недавнему прошлому)
и исторической (давней) информации. Очевидно, что здесь потребуется специализированное
промежуточное ПО. В зависимости от корпоративной информационной среды в этом
качестве могут использоваться серверы приложений и другие средства интеграции.
- Теперь можно наконец формировать аналитику, одновременно осуществляющую мониторинг и анализ абстрагированной информации. Типы аналитики и состав инструментов здесь определяются потребностями бизнеса. В простых случаях часто бывает достаточно рудиментарных средств мониторинга и статистики, в более сложных ситуациях понадобятся мощные программы с такими возможностями, как прогнозирование или регрессивный анализ. Так как все инструменты работают с одной и той же абстрагированной информацией, их можно будет применять к ней в любом порядке, а также сочетать друг с другом.
Новая архитектура
Чтобы технологически сочетать интеграцию приложений с BI, необходимо выстроить новую аналитическую архитектуру. Эта архитектура в общем виде должна включать ряд компонентов: адаптеры, трансляторы (реального времени и пакетные), хранение оперативных данных, анализ (реального времени, исторический и комбинированный).
Насчет адаптеров все ясно — ими комплектуется практически любой имеющийся на рынке программный пакет EAI, они обеспечивают критически важную связь между системой-источником (такой, как база данных или ERP-приложение) и инфраструктурой EAI/BI. Надо только учесть, что их назначение — не репликация информации, являющаяся традиционной областью применения адаптеров, а скорее обеспечение доступа к данным. Важно также заметить, что с любой системой непрактично использовать более одного адаптера, поскольку всякий адаптер уже решает две задачи — он должен, во-первых, обслуживать все аспекты репликации данных для поддержки бизнес-процесса, а во-вторых, обеспечивать доступ к информации для аналитических систем реального времени.
Трансляторы, в соответствии со своим названием, отвечают за преобразование содержания информации, что нужно для создания единого абстрагированного контента, используемого для аналитики. Они должны преобразовывать данные как в режиме реального времени (для поддержки текущих бизнес-процессов), так и в пакетном режиме (для поддержки более традиционных видов деятельности типа ETL). Хранение нужно для захвата текущих данных, которые вскоре превратятся в данные недавнего прошлого, а затем и в исторические. В мире традиционной EAI для этой цели служил механизм так называемых хранилищ сообщений (message warehousing), где данные реального времени фиксировались и автономно сохранялись для различных целей (обычно для рудиментарного анализа). В контексте интегрированной аналитической системы предполагается, что компонент хранения будет действовать как источник информации, не являющейся ни оперативной, ни исторической.
Хотя трансляторы и выполняют некоторое абстрагирование при подготовке текущих данных к просмотру, нам нужно абстрагировать эту информацию дальше и объединить ее с информацией другого временного типа. Компоненты, служащие для этой цели, мы называем абстракторами. Абстракторы комбинируют старое и новое, обеспечивая единый взгляд на данные.
Наконец, аналитическая компонента используется для «нарезания» информации на нужные нам «ломтики», извлечения именно тех данных, которые позволят принять верное решение с учетом всей релевантной информации, относящейся как к текущему состоянию бизнеса, так и к его предыдущим состояниям. Еще раз отметим, что в этом случае рассматривается вся текущая и прошлая информация, в то время как традиционные инструменты BI работают только с агрегированными относительно старыми данными, а традиционный мониторинг — только с данными реального времени.
***
Миры EAI и BI пока различны, хотя имеют общие технические требования, типовые
решения и задачи. Однако, на мой взгляд, их объединение — лишь вопрос поиска
синергии и создания «убойной технологии». При правильном применении в корпоративной
среде эта технология принесет огромную прибыль. Организации получат предельную
видимость собственного бизнеса, все его аспекты будут не только понимаемы, но
и размещаемы в контексте его истории.
