Исследование технологий интеграции систем

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

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

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

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

Подобные системы внедряются в существующую ИС-архитектуру компании с целью достижения определенных результатов:

ѕ частичное снятие загруженности с серверов текущей информационной среды;

ѕ внесение новых возможностей, например:

- для выполнения задач прогнозирования поведения Клиентов;

- прогнозная аналитика (поведение Клиентов, рост/спад продаж и др.);

- поддержка принятия управленческих решений;

ѕ оптимизация бизнес-процессов.

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

Проблема интеграции ИС обостряется особенно в гетерогенной среде, поскольку встроенные механизмы в коммерческих системах управления базами данных (СУБД) не рассчитаны на работу в таких условиях. При этом проблема еще более усложняется при создании динамически адаптируемых ИС, допускающих реструктуризацию данных, т.к. структуры БД в локальных узлах могут различаться, что усложняет процесс реплицирования: требуется тиражировать и синхронизировать не только данные, но и их структуру [4].

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

В данной работе рассматривается проблема интеграции на различных уровнях (данных, систем и др.) на примере существующей биллинговой системы компании АО «Эр-Телеком Холдинг» и подключаемых систем бизнес-аналитики. Описание биллинговой системы компании приведено в п. 2.1.

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

В данной работе предлагается метод интеграции сторонних систем анализа и обработки данных в существующую ИС-архитектуру компании, который позволяет:

ѕ легко внедрять/настраивать системы бизнес-аналитики;

ѕ изменять существующие настройки функционирования подключенной системы;

ѕ не вносить существенных изменений в существующую архитектуру ИС компании при каждом новом внедрении сторонней системы;

ѕ шаблонной интеграции с бизнес-процессами компании.

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

Развитию интеграции на уровне данных, бизнес-процессов, а также на уровне композитных приложений посвящены такие работы, как «Методы интеграции данных в информационных системах» М.Р. Когаловского [4], «Обзор современных методов интеграции данных в информационных системах» С.В. Шибанова [25], а также компании, например, Gemini Systems [31] и др. Подробный обзор существующих работ приведен в п. главе 1.

Объектом исследования является существующая архитектура ИС компании, а также подключаемые системы аналитической обработки данных.

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

Целью магистерской диссертации является разработка метода интеграции сторонних систем аналитической обработки данных к общей архитектуре ИС компании.

Метод интеграции разрабатывается с применением результатов внедрения систем IBM SPSS и IBM Campaign Management.

Для достижения поставленной цели были сформулированы следующие задачи:

ѕ исследовать существующую архитектуру ИС компании для формирования представления обо всех используемых сущностях (серверах) и связях между ними;

ѕ исследовать методы интеграции систем, решений, данных из гетерогенных источников для проведения сравнительного анализа и принятия оптимального решения для существующей архитектуры ИС компании;

ѕ проанализировать экономические показатели инвестиционных проектов по внедрению систем аналитической обработки данных на примере проектов сбора витрины данных для IBM SPSS и IBM Campaign Management для последующего сравнения значений показателей с из без применения разработанного метода интеграции;

ѕ разработать метод интеграции подключаемых систем к общей архитектуре ИС компании, отвечающий следующим требованиям:

- адаптация к существующей архитектуре ИС компании;

- сокращение срока интеграции с существующими системами;

- возможность гибкой корректировки конфигурации;

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

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

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

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

1. Исследование технологий интеграции систем

По результатам данного исследования необходимо выявить недостатки и ограничения существующих технологий интеграции. Для проведения исследования необходимо определить подходящие для задач исследования понятия и методологии. В пункте ниже приведен анализ понятий интеграция на различных уровнях и Business Intelligence.

Кроме того, требуется проанализировать состояние исследований в области использования различных технологий для анализа данных и обосновать преимущество создания метода интеграции.

1.1 Понятийный аппарат в сфере интеграции ИС

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

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

ѕ интеграция данных характеризуется слиянием информационных потоков из гетерогенных источников в единое хранилище данных [25];

ѕ интеграция бизнес-процессов, при осуществлении которой внимание уделяется решению проблем интеграции на основе общих бизнес-процессов различных предприятий с учетом специфики каждого из них в области автоматизации управления [17];

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

Так, интеграция данных - это технология объединения текущих и исторических данных из систем оперативной обработки данных, для выявления тенденций и прогнозирования будущих результатов, и создания информационной инфраструктуры, удовлетворяющей стратегическим проектам Business Intelligence (BI) [25]. При интеграции данных используются технологии, такие, как ETL (extract, transform and load), EII (enterprise information integration), EAI (enterprise application integration) и др. [35].

В свою очередь, интеграция бизнес-процессов подразумевает технологию организации взаимодействия информационных систем различных предприятий, которая отвечает за техническую реализацию обмена данными, используя Web-сервисы, с помощью которых можно создавать программные приложения на основе существующих бизнес-процессов организации (SOA) [4]. Однако, для достижения поставленной цели и решения выявленных задач далее будет использоваться понятие интеграции. Интеграция может существовать в рамках ИС, данных, бизнес-процессов и др. В ИС интеграция означает объединение функциональных возможностей компонент системы, которые являются отдельными ИС и могут существовать агрегировано от комплексной системы, и задание правил их взаимодействия.

Когаловский М.Р. в своем исследовании [4] использует следующее понятие интеграции: интеграция - это не просто механическое объединение модулей информационной системы. При разработке плана интеграции исходят прежде всего из стратегических целей развития предприятия, возможного изменения бизнес-логики, в соответствии с которой выстраиваются бизнес-процессы и осуществляется их информационное сопровождение. Интеграция может производиться на уровне форматов и баз данных, программно-аппаратных и сетевых устройств, пользовательских интерфейсов, форм и шаблонов документооборота, программных приложений и т.д. Выгоды от такой интеграции очевидны. Необходимо отметить, что в рамках данного исследовании использование такого определение понятия «интеграция» является уместным.

Поскольку в данной работе исследуется проблема интеграции BI-систем в общую ИТ-инфраструктуру компании, необходимо установить точное понятие инструмента построения BI.

В аналитическом отчете 2013 года «Системы бизнес-аналитики в России 2013 BI» центра выбора технологий и поставщиков TADVISER [1] одним из лучших определений Business Intelligence признано определение, данное неизвестным автором. По его мнению, Business Intelligence - знания, добытые в бизнесе с использованием различных аппаратно-программных технологий. Такие технологии дают возможность организациям превращать данные в информацию, а затем информацию в знания.

Data Warehouse Institute предложено следующее определение Business Intelligence: «Business Intelligence имеет отношение к процессу превращения данных в знания, а знаний - в действия бизнеса для получения выгоды». Является деятельностью конечного пользователя, которую облегчают различные аналитические и групповые инструменты и приложения, а также инфраструктура хранилища данных.

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

Глоссарий www.sdgcomputing.com/glossary.htm избегает напрямую говорить о business intelligence, а ведет речь об инструментах бизнес-интеллекта (business intelligence tools), но в контексте данных, информации и знаний [2]: «Инструменты business intelligence - программное обеспечение, которое позволяет бизнес-пользователям видеть и использовать большое количество сложных данных. Знания, основанные на данных, (data-based knowledge) получаются из данных с использованием инструментов business intelligence и процесса создания и ведения хранилища данных (data warehousing)».

1.2 Анализ существующих методов интеграции

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

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

Вопросам интеграции информационных систем, интеграции методов и данных выделено большое место в научных работах исследователей. Например, ведущий научный сотрудник Института проблем рынка РАН М.В. Когаловский [10] в своей работе «Интеграция данных в информационных системах» привел сведения о состоянии исследований и разработок в области интеграции данных из множества независимых неоднородных источников. Когаловский М.Р. подчеркивает, что в системах интеграции данных наибольшее распространение получила архитектура с посредником и что чаще всего используются две разновидности архитектуры с посредником: Global as View и Local as View [10].

Факторы, влияющие на интеграцию [23]:

ѕ Ускорение процессов. Развитие компании требует частой смены структуры данных, бизнес-процессов, пользовательских интерфейсов и др. В таких динамичных областях задача интеграции наиболее актуальна.

ѕ Распределенность. Компании становятся все более крупными, а решаемые задачи все более комплексными, появляется логическая, организационная и географическая рассредоточенность.

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

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

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

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

ѕ Интерактивность. Потребители информации постоянно повышают свои ожидания о скорости реакции системы, быстродействии и оперативности доставки информации. Большинство процессов стремятся к выполнению в реальном времени.

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

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

ѕ Высоконагруженность. На сложность интеграции влияют: количество пользователей в системе, интенсивность потока обработки данных, объемы данных и ресурсоемкость вычислений.

ѕ Непрерывность цикла работы. Интеграция и обновление систем должны проводиться без остановки их функционирования, плавно, постепенно и незаметно для организации и пользователей.

ѕ Межсистемная интеграция. Задачи стыковки не ограничены рамками организации, все чаще нужно интегрироваться с партнерами, клиентами, поставщиками, подрядчиками и даже государственными структурами.

Сложность интеграции определяется следующими параметрами:

ѕ концептуальная разница - основывается на том, что разработчики разных систем изначально приняли разные решения, предположения и допущения, которые концептуально не стыкуются между собой [23];

ѕ технологическая разница - несовместимые форматы обмена данными, протоколы взаимодействия и интерфейсы;

ѕ несовместимость лицензий;

ѕ стандартизация - важность использования как можно больше международных, государственных и отраслевых стандартов;

ѕ интеграция на уровне брокеров;

ѕ интеграция на уровне данных - возможность обращения несколькими приложениями в одну или несколько БД, связанных репликациями;

ѕ интеграция на уровне сервисов;

ѕ интеграция на уровне пользователя;

ѕ дополнительная интерпретация метаинформации.

Существуют лучшие практики минимизации негативного влияния этих параметров. К примеру, при концептуальной разнице решением может послужить введение еще одного слоя абстракции, который концептуально не противоречит обоим подходам. При этом, есть два варианта реализации [23]:

ѕ получившаяся система становится централизованной, а две и более интегрируемых системы превращаются в подсистемы;

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

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

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

Еще одним интересным методом интеграции является динамическая интерпретация метаинформации. Этот подход основан на построении моделей предметной области и повышения абстракции программных компонентов и структур данных.

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

Потребность:

Необходимо интегрировать N информационных систем, характеризуемых факторами (см. п. 1.2). Количество прослоек, конвертеров, брокеров и интерфейсов между ними должно быть минимальным.

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

Задачи интеграции возникают в случае внедрения в компанию новых ИС или добавления в существующие системы новой функциональности. При интеграции информационных систем производится интеграция именно данных, и только потом техническая реализация канала, способа, формата передачи данных. В связи с этим, основной проблемой, возникающей при интеграции, является проблема, связанная с качеством данных [4].

Особенно ситуация становится актуальной в случае интеграции базы знаний о клиентах (Customer Data Integration, CDI) при объединении компании (слиянии и поглощении, M&A). Для этого требуется консолидация хранилищ имен, адресов, истории клиентов и др. При отсутствии единого метода интеграции данных существует риск получить в результате несогласованные данные в приемнике с дублированными или конфликтующими атрибутами клиентов.

В данном случае компания может воспользоваться системами управления мастер-данными (Master Data Management, MDM). В отсутствие единой MDM-системы в компании задачи согласования данных и обеспечения их качества ложатся на процессы интеграции. Для этого разрабатываются бизнес-правила преобразования данных, создаются таблицы соответствия и т.п. решения, что по сути своей представляет систему MDM для одного или группы интеграционных процессов [4].

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

Одной из основных проблем, стоящих перед разработчиками многих современных ИС, является постоянное изменение требований и условий деятельности учреждений, объединенных использованием единой ИС. Изменения должны оперативно вноситься в функционирующие компоненты по возможности без переписывания программного кода. Поэтому разрабатываемые компоненты тиражирования должны учитывать возможность модификации модели предметной области (БД, пользовательского интерфейса, шаблонов отчетов и бизнес-процессов, в частности, появление новых операций и пр.). Реализация таких функций обеспечивает расширяемость, адаптируемость ИС к новым условиям [7].

Многие системы тиражирования основаны на синхронной схеме реплицирования, при которой узел-поставщик данных отслеживает результат фиксации отправленных данных на узле-приемнике. Отличительной особенностью предлагаемого подхода к тиражированию является отсутствие требования постоянного оперативного (on-line) соединения между узлами. Это может оказаться необходимым в условиях ненадежных каналов связи и позволяет передавать пакет тиражирования любым удобным способом (на носителе, по электронной почте и т.д.). Возможность тиражирования данных ИС в асинхронном режиме - одна из основных задач [7].

Одним из распространенных методов интеграции данных является схема интеграции, основанная на классификации технологий интеграции данных из шести уровней, которую предложил исследователь из Цюрихского университета Клаус Диттрих (см. рисунок 1).

Шесть уровней интеграции по Клаусу Дитриху [21]:

ѕ Common Data Storage (Общие системы хранения). Осуществляется за счет слияния данных из разных систем хранения данных в одну общую. Сегодня мы бы объединили эти два уровня в один и назвали бы его виртуализацией систем хранения.

ѕ Uniform Data Access (Унифицированный доступ к данным). На этом уровне осуществляется логическая интеграция данных, различные приложения получают единообразное видение физически распределенных данных. Такая виртуализация данных имеет свои несомненные достоинства, но гомогенизация данных в процессе работы с ними требует значительных ресурсов.

ѕ Integration by Middleware (Интеграция средствами ПО промежуточного слоя). ПО этого слоя играет посредническую роль, его составляющие способны к выполнению отдельных предписанных им функций, в полном объеме интеграционная задача решается во взаимодействии с приложениями.

ѕ Integration by Applications (Интеграция средствами приложений). Обеспечивает доступ к разным источникам данных и возвращает пользователю обобщенные результаты. Сложность интеграции на этом уровне объясняется большим разнообразием интерфейсов и форматов данных.

ѕ Common User Interface (Общий пользовательский интерфейс). Дает возможность единообразного доступа к данным, например, с помощью браузера, но при этом данные остаются неинтегрированными и неоднородными.

ѕ Manual Integration (Интеграция вручную). Пользователь сам объединяет данные, применяя различные типы интерфейсов и языки запросов.

Относительно новым подходом к интеграции данных является семантический подход. В отличие от синтаксического подхода он основывается не на внешнем сходстве объединяемых данных, а на содержательной компоненте.

В источнике [10] авторы рассматривают так называемые ODBA (Ontology-Based Data Access Systems) системы. Сравнивают различные подходы к построению систем: реляционный, объектный, логический, дескриптивные логики, онтологии. Рассматривается ряд систем: QuOnto, ROWLkit, QToolKit, DIG Server wrapper, MASTRO. Все эти системы используют онтологии. Онтология используется в качестве концептуальной схемы для интеграции данных из гетерогенных источников. Все перечисленные системы основаны на LD-Lite логике, имеют графический интерфейс и могут подключаться к большому числу баз данных.

В источнике [19] решается задача каталогизации и интеграции разнородных источников данных. Также предлагается метод, основанный на онтологиях. Рассматриваются проблемы интеграции данных. Ставится задача, не внося изменений в существующие источники данных, предоставить к ним доступ по принципу «единого окна», а также предоставить возможность «семантической окраски» данных для дальнейшей машинной обработки. Авторы предлагают использовать дескрипционные логики для описания семантики источников и онтологии как инструмент представления обобщенных спецификаций. Авторы предлагают медиаторную архитектуру системы для решения данных задач. Центральное место занимает онтология-классификатор для описания предметных областей на высоком уровне. Кроме того, создаются расширяющие онтологии-отображения, которые отображают классы и свойства на реальную структуру источника.

В [13] рассматривается возможность применения онтологий для интеграции данных АСУ предприятия. Решается задача интеграции онтологий, извлеченных из источников данных. Для этого используется базовая онтологическая модель промышленного предприятия, которая позволяет осуществить глубокую интеграцию разнородных данных и избежать лексических и семантических конфликтов, а также специальный алгоритм определения семантической близости понятий.

В источнике [33] авторы ставят задачу интеграции данных из гетерогенных источников. Как и в некоторых рассмотренных ранее системах предлагается медиаторный подход к проектированию системы. Центрально место в системе (медиатор) занимает онтология SEMANCO. При помощи этой онтологии интегрируется техническая и статистическая информация о зданиях, которая располагается в структурированных гетерогенных источниках.

В статье [26] описывается подход для доступа к гетерогенным источникам, описанным при помощи xml. Онтология играет роль интерфейса между конечными пользователями и xml-источниками, предоставляет гомогенное семантическое представление xml описаний данных, чтобы поддержать формулирование запросов на семантическом уровне, не заботясь о структуре и синтаксисе каждого описания. Онтология определяет и поддерживает проекции между онтологическими схемами и данными в источниках. Свои идеи авторы воплотили в системе VISPO. Онтология организована в 3 уровня: уровень семантического проецирования, промежуточный уровень, категоризирующий уровень.

В [32] глобальная онтология определяет все термины и понятия онтологии домена, кроме того, на дополнена связями с глобальными репозиториями онтологий, которые содержат разработанные и специфицированные предметные онтологии, каждая из которых описывает контент всех источников данных из домена. Система, предлагаемая авторами, предполагает агентный подход. Есть агент для построения запроса, проецирующий агент, который сопоставляет запрос и предметную онтологию, далее транспортный агент перемещается на источник и получает данные.

Компания Progress Software выпустила семантический интегратор DataXtend Semantic Integrator.Progress. Он предоставляет единую модель данных, делающую возможной семантическую интеграцию данных различных информационных структур [25]. DataXtend позволяет сохранять бизнес-целостность данных при коллизиях между системой-источником и системой-приемника. Коллизии могут быть выражены в несхожести представлений систем о структуре данных. Использование решения семантической интеграции данных DataXtend позволяет предприятию ограничиться для приложений только слабо связанными интерфейсами и обеспечивает слабую связанность на семантическом уровне [33].

Семантический сервер компании «Алтимета» позволяет в реальном времени превратить разрозненные данные организации в полноценную бизнес-информацию, пригодную для принятия эффективных решений. Семантический сервер обеспечивает интеграцию приложений с использованием архитектуры SOA и подходов интеграционных процессов - BPEL, BPMN [25]. Семантический сервер применяет семантические стандарты к SOA-архитектуре и позволяет:

ѕ консолидировать не только справочники и классификаторы, а вообще всю информацию, которую необходимо совместно использовать интегрируемым системам;

ѕ объединить, интегрировать информацию и гарантировать качество данных;

ѕ обеспечить получение информации из слабоструктурированных источников;

ѕ производить автоматическую классификацию данных и логический вывод.

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

По мере роста и развития корпоративной информационной инфраструктуры нередко оказывается, что отдельные ее подсистемы, выросшие из небольших и, как правило, разнородных приложений, «говорят на разных языках», основаны зачастую на разных СУБД, используют разные протоколы и разные форматы хранения информации [30].

Проблема интеграции на уровне приложений актуальна не только в случаях покупки готовых решений и их адаптации под существующую инфраструктуру ИТ в компании, но и в случаях внутрикорпоративной разработки. Причина заключается в том, что программные продукты могут быть куплены у разных поставщиков и имеют слабую связь между собой (тяжело настраиваемые точки взаимодействия). Группа задач, решающих эти проблемы, объединяется под названием Enterprise Application Integration (EAI) - интеграция систем (приложений) предприятия [15].

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

Основные требования к интеграции приложений [6]:

ѕ cвязь по различным протоколам (HTTP, E_mail, File);

ѕ XML - как основной формат данных при обмене;

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

- компоненты расширения базового набора протоколов,

- компоненты нестандартной логики при обработке документа;

- компоненты для изменения формата отправляемого или получаемого документа;

ѕ надежность при отправке и получении документов.

ѕ нетребовательность к программным и аппаратным ресурсам.

ѕ мониторинг обработанных документов, ошибок и событий системы.

ѕ маршрутизация документов.

К примеру, на сегодняшний день существует и активно развивается технология BizTalk Framework [15], основанная на XML, SOAP и открытости систем, применяющаяся для организации документооборот.

Специалисты Gartner предполагали, что к 2006 году более 60% компании будут внедрять сервис-ориентированную архитектуру (Service-Oriented Architecture - SOA) как основу для решения свой бизнес-целей. Так, в настоящее время при проектировании и реализации КИС всё чаще применяется сервис-ориентированная архитектура и существует тенденция к переходу от «монолитной» системы к сервисам, микросервисам.

SOA понимается как парадигма организации и использования распределенного множества функций, которые могут контролироваться различными владельцами. Базовыми понятиями в такой архитектуре являются «информационная услуга» и «композитное приложение» [8].

Становление и развитие SOA происходило на базе практических требований бизнеса, заключавшихся, прежде всего, в разумной экономии программных и технологических средств и затрат на реализацию и сопровождение информационной инфраструктуры [8]:

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

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

ѕ обеспечивать реализацию различных типов интеграции:

- пользовательская интеграция (User Integration) - обеспечение взаимодействия информационной системы с конкретным персонифицированным пользователем;

- интеграция приложений (Application Connectivity) - обеспечение взаимодействия приложений;

- интеграция процессов (Process Integration) - интеграция процессов в соответствии с бизнес-логикой деятельности предприятия;

- информационная интеграция (Information Integration) - интеграция с целью обеспечения доступности информации и данных;

- интеграция новых приложений (Build to Integrate) - интеграция новых приложений и сервисов в существующие информационные системы.

ѕ обеспечивать поэтапность внедрения вновь созданных и миграции существующих информационных систем;

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

ѕ позволять реализацию различных моделей построения информационных систем, в особенности таких как портальные решения, grid-системы и on-demand-системы.

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

Построение модели предметной области с помощью описания структур данных и программного кода является классическим подходом в разработке ИС. Зачастую модель предметной области является статической, например, на период использования определенной версии ПО. Но в текущий момент все чаще становятся актуальными задачи, требующие гибкого изменения модели. При этом, задействуется время разработчиков ПО, время на пересборку компонентов архитектуры решения, к которым были применены изменения, возможно прекращение работы системы на время внесения изменений (если система уже сдана в эксплуатацию) и др. Сфера применения технологии динамической интерпретации метаинформации распространяется на системы аналитической обработки данных, СППР, системы интеграции между компаниями-партнерами (или других вариаций M&A).

Необходимо ограничить класс задач, которые требуют принципиально другого подхода:

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

ѕ задачи обработки слабо-связанных данных или данных с непостоянными структурой, параметрами или логикой обработки;

ѕ задачи, в которых количество классов обрабатываемых объектов сравнимо с количеством их экземпляров или количество экземпляров всего на один-два порядка выше;

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

ѕ задачи межкорпоративного обмена данными, межсистемной интеграции (включая интеграцию гетерогенных распределенных приложений),

ѕ прикладные задачи, не связанные с массовым пользователем.

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

При повышении уровня абстракции возникают сложности программных компонентов и структур данных:

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

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

Необходимо отметить, что этой проблеме посвящено множество работ. К примеру, в работе Ступникова С.А. [18] рассматривается понятие канонической модели, которая должна обладать формальной интерпретацией для построения формальных моделей прикладных областей и компонентов, отражающих их статические и динамические свойства. В качестве канонической модели рассматривается СИНТЕЗ - язык спецификации и проектирования интероперабельных сред неоднородных информационных ресурсов.

В другой работе [20] рассматривается проблема невозможности заранее предсказать развитие предметной области, что может привести к необходимости пересмотра обменного формата. Также описывается язык спецификации данных FlexT (Flexible Types), который позволяет описывать интерпретацию статических данных, в первую очередь в виде идентификации типов.

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

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

2. Анализ процесса внедрения сторонних систем в архитектуру ИС компании

В данной главе приведена характеристика текущей архитектуры информационных систем компании. Описаны основные компоненты архитектуры. Приведено обоснование совершенствования и внесения изменений в текущую архитектуру ИС компании.

Внесения изменений сопровождаются внедрением новых систем в рамках инвестиционных проектов. Как пример, в данной главе рассматриваются инвестиционные проекты по внедрению систем и создания для них информационного наполнения (витрин данных):

ѕ IBM SPSS;

ѕ IBM Campaign Management.

2.1 Существующая архитектура ИС компании

На серверах биллинга БД находятся под управлением СУБД Oracle, БД в области подготовки данных также находится под управлением СУБД Oracle. Необходима возможность расширения списка источников данных для области подготовки данных, БД источников могут находиться под управлением различных СУБД. Репликация баз биллинга в область подготовки данных не должна влиять на предоставляемые компанией услуги.

Техническая архитектура содержит область подготовки данных. Сервер SA обеспечивает при попытке внедрить автоматизированную систему бизнес-аналитики отразить чувствительность к работоспособности сети. Сервер подготовки данных (SA) обеспечивает бесперебойную работу ETL-процедур. Сервер SA (Stage Area) выступает единой точкой сбора реплицированных данных со всех серверов биллинга.

Архитектура ИС, включающая область подготовки данных минимизирует влияние сбоев в сети на процесс сбора кубов данных, а также ускоряет работу ETL процедур за счёт консолидации данных. Также область подготовки данных предоставляет возможность реализации оперативных отчётов, основанных на таблицах, находящихся в SA-области.

Сервера биллинга. Хранятся БД биллинга.

ORACLE_SID=billing

ПО: Pacemaker

Сервисы: автоматизированное рабочее место (АРМ).

Сервера Авторизации Клиентов. Хранятся БД авторизации.

ORACLE_SID=raddb

ПО: Pacemaker

Сервисы:

ѕ авторизация и аккаунтинг интернет сессий (vserver radius_server);

ѕ авторизация и аккаунтинг гор.связь (vserver grsv_radius);

ѕ авторизация и аккаунтинг гор.связь (vserver wifi_radius);

ѕ A5 (grsv_radius);

ѕ авторизация и аккаунтинг сетевого оборудования (vserver net_radius);

ѕ установка скоростей сетевого оборудования BRAS Juniper E-120.

Cервер Статистики. Хранятся БД статистики и потребления услуг.

ORACLE_SID=parser

ПО: Pacemaker, Runit, NFS сервер. Резервное копирование: Bacula, RMAN.

Cервисы:

ѕ хранение и обработка статистики;

ѕ виртуальные машины сollect:

- oramon1/2: Мониторинг Oracle, RMAN;

- bacula2: Сервис Bacula;

- db1_city: дочерний город DB.

Сервера WEB.

ПО: Pacemaker, nginx\Apache

Сервисы:

ѕ личный кабинет Гор.Связь (cab-gs1\2);

ѕ Plat;

ѕ Https прокси для Oracle;

ѕ агент PPO (Oracle client);

ѕ сервис Puppet: автоматизирует настройку и управление.

2.2 Подключаемые в ИТ-инфраструктуру компании сторонние системы разработчиков

В данном пункте представлено описание подключаемых к общей архитектуре ИС компании систем. Описание систем является справочной информацией для формирования общего представления о использовании сторонних продуктов внутри компании. В качестве примеров ниже описаны две системы: IBM SPSS и IBM Campaign Management. Обе системы были приобретены компанией для решения задач автоматизации Клиентского опыта компании.

Примерами подключаемых систем в данной работе выступают продукты компании IBM - IBM SPSS Modeler [29] и Campaign Management [26]. Инструмент SPSS может использоваться как платформа для прогнозной аналитики, позволяющая применять и обрабатывать информацию о Клиентах компании, получая в результате выборки информации о Клиентах в зависимости от цели построения прогностической модели, например, выборка Клиентов, склонных к оттоку, выборка Клиентов для осуществления «допродаж» и др.

В свою очередь, Campaign Management отвечает за управление коммуникациями в компании с целями осуществления коммуникаций только с теми Клиентами, которые готовы для коммуникации, только по тому каналу коммуникации (e-mail, обзвон, СМС-информирование и др.), по которому Клиенту наиболее удобно получать информацию.

Результаты моделирования в SPSS позволяют получить выборку Клиентов с целевой характеристикой (например, склонные к оттоку). Campaign Management использует эту выборку Клиентов для настройки коммуникации с ними.

SPSS Modeler [29] - это программный комплекс, позволяющий строить прогностические модели и применять эту информацию при принятии решений на уровне отдельных клиентов, групп, систем. Программный комплекс представляет собой набор алгоритмов и технологий, позволяющий выявлять неочевидные закономерности в данных, и оперативно внедрять полученные результаты.

SPSS работает только с плоскими, структурированными таблицами.

Главная задача, которую решает SPSS, и которая коррелирует со многими областями деятельности Службы управления клиентских данных: выявлять закономерности в данных.

Прикладные задачи, решаемые с помощью SPSS:

ѕ поведенческая сегментация Клиентов;

ѕ построение прогностических моделей для стимулирования дополнительных продаж;

ѕ построение прогностических моделей для поиска Клиентов, склонных к оттоку.

Витрина SPSS - это хранилище данных, содержащее комплексную информацию о клиентах, их транзакциях и взаимоотношениях с компанией.

На основании витрины данных, строятся более мелкие таблицы для обучения и применения моделей. Построенные в SPSS модели будут использоваться как средство обоснования принятия решений:

ѕ модели для сегментирования клиентов будут использоваться для формирования посылов коммуникации, разработки новых продуктов на основании сегментов и для них;

ѕ модели для допродаж услуг будут использоваться для приоретизации предложений Клиентам, для оптимизации допродаж и увеличения их эффективности;

ѕ модели по оттоку будут использоваться для работы с проактивным сохранением Клиентов, редуцировании возможного оттока.

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

Важно, чтобы показатели отражали основные точки взаимоотношений Клиента с компанией и характеризовали его:

ѕ состав услуг, и их использование Клиентом;

ѕ активность Клиента;

ѕ платежи;

ѕ проблемы с услугами;

ѕ история обращений;

ѕ пользование программой лояльности;

ѕ рекламные акции, примененные к клиенту;

ѕ статистика по «телесмотрению»;

ѕ данные об оборудовании.

Каждое поле в витрине данных соответствует отдельным показателям. Общее количество показателей витрины данных SPSS - 600. В рамках сопровождения проекта «Витрина данных для SPSS» возможна доработка реализованных показателей и создание новых показателей по требованию бизнеса.

На текущий момент существует подобная витрина данных SPSS, однако она является устаревшей и содержит малое количество показателей (около 200). Существующая витрина данных доступна на сервере SA, название таблицы - ma_fact_stat_all.

Существующая витрина данных SPSS логически выстроена с уровня договора. Реинжиниринг витрины необходим вследствие того, что все коммуникации с Клиентом переходят на более высокий уровень абстракции - на Клиента. Таким образом, при создании новой витрины данных выделен отдельный блок «Клиент».

На текущий момент услуги договора привязаны к договору и, в случае, если Клиент заключит новый договор, все услуги будут привязаны к новому договору. Таким образом, не обеспечивается атомарность данных на логическом уровне и удобство работы с данными Клиента для сотрудника компании.

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

Все данные в витрине собираются в разрезах Клиента и месяца.

К витрине SPSS предъявляются следующие общие требования:

ѕ таблицы должны хранить данные по параметрам в ежемесячном разрезе по уникальному идентификатору, аналогично текущей витрине SPSS;

ѕ таблицы должны обновляться за предыдущий месяц до 10-го числа текущего месяца;

ѕ требования к характеристикам Клиентов, данные по которым должны быть представлены в витрине SPSS:

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

ѕ в витрину не должны попадать данные по Клиентам, у которых:

- 2 года отсутствует активность по договорам, т.е. все их договоры являются расторженными или не подключенными;

- существуют следующие атрибуты договора: «Технологические», «Технические» и «Тестовые» договоры;

- юридические лица (Клиенты блока b2b);

- договоры, которые проходят проверку на двойные без привязки к сроку и не проявляют активности, например, отказные договоры (по которым найден факт расторжения договора);

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

Задачей проекта по внедрению Campaign Management является автоматизация полного цикла проведения кампаний, включая:

ѕ сегментацию и отбор Клиентов;

ѕ применение коммуникационной политики;

ѕ назначение сегментам предложения;

ѕ определение каналов коммуникации и их последовательности;

ѕ передача заданий на коммуникацию в канал;

ѕ сбор и хранение откликов;

ѕ подготовка отчетов по эффективности кампаний.

В результате внедрения ожидается:

ѕ увеличение объемов вторичных продаж, которое достигается за счет:

- увеличения количества запускаемых кампаний;

- сокращения времени на подготовку проведения кампании (time to market);

- увеличения процента откликнувшихся Клиентов;

- увеличения количества используемых каналов;

ѕ повышение эффективности кампаний, которое достигается за счет:

- сокращения расходов на нерезультативные контакты при проведении таргетированных кампаний;

- более тонкого сегментирования клиентской базы;

- снижения издержек на коммуникации;

- анализа результатов проведения кампаний;

ѕ увеличение лояльности клиентов, которое достигается за счет:

- уменьшения перекоммуникации с клиентом за счет применения контактной политики;

- использования наиболее релевантных каналов для каждого клиента;