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

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

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

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

- единой истории коммуникации с клиентом и откликов на предложения;

- выбора наиболее эффективных кампаний при проведении пилотов.

В данном пункте представлено описание подключенных систем к общей инфраструктуре ИС компании.

В случае IBM SPSS:

Вследствие того, что сбор данных с городов и их расчет в пакетах на builddev и designdb сильно нагружает схему, принято решение перенести расчет показателей на схему SA. Таким образом, данные не собираются по городам и реплицироваться на SA, весь расчет сразу будет происходить на SA. На SA все таблицы с данными (clients, agreements и т.д.) имеют поле billing_id.

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

Пользователи авторизуются с использованием своих доменных УЗ и доменных паролей в системе по прямой ссылке http://eskk-app1.hq.ertelecom.ru:9080/unica. Пользователи, который не имеют доступа к системе могут обратиться к администратору системы и запросить создание учетной записи и выдачи соответствующих прав. Запрос на добавление УЗ должен сопровождаться подтверждением от руководителя подразделения (в тексте электронного письма, сообщением в Lync, звонком администратору). Более подробно данный процесс описывается в п.5 настоящего документа.

Система IBM Campaign имеет 2 сервера приложений - Application (eskk-app1.hq.ertelecom.ru) и Analytics (eskk-alt1.hq.ertelecom.ru). Сервер Application предназначен для предоставления пользовательского web-интерфейса и логики его работы. Составляющими для него являются веб-приложения Marketing Platform, Campaign. Сервер Analytics - ответственный за выполнение логики диаграмм кампаний, его составляющая - Campaign Server. Система сообщается с сервером SMTP с использованием TCP порта 25, а с сервером LDAP по 3268 порту. Синхронизация проходит с участием компоненты Marketing Platform (Platform). Данная компонента так же общается напрямую с таблицами внутри БД DWH c использованием порта 1521.

Компонента Campaign сервера Application прослушивает TCP порт 4664 для синхронизации с слушателем на сервере Analytics. Слушатель системы Campaign - unica_aclsnr позволяет клиентским приложениям, таким как, веб- приложение Campaign, соединяться с аналитическими back-end процессами. Слушатель автоматически вызывает отдельный процесс unica_acsvr для каждого залогированного пользователя и для каждой активной диаграммы. Например, если один пользователь залогинился в системе и затем открыл диаграмму, слушатель порта создаст 2 экземпляра процесса unica_acsvr. Также слушатель системы, используя порт 1521, общается со следующими объектами в БД DWH:

CMDM - витрина данных (DWH), используется для сегментации и выявления целевых действий;

Campaign - системные таблицы, истории откликов и контактов;

Exchange - обеспечивает интеграцию с каналами связи;

Stage - хранение временных таблиц для данных по откликам 1 и 2 типа;

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

Также используется БД SA для сегментации по неагрегированным данным.

3. Разработка решения по гибкой интеграции сторонних систем в ИТ-инфраструктуру компании

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

В качестве вариантов интеграции рассмотрены следующие:

ѕ данных;

ѕ бизнес-процессов;

ѕ приложений (сервисов).

Предлагается внедрение связки из следующих компонентов:

ѕ Billing + BI - существующие сервера компании (текущая архитектура ИС);

ѕ технологии динамической интерпретации метаинформации;

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

3.1 Интеграционная платформа ESB как средство оптимизации подключения внешних систем к ИТ-инфраструктуре компании

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

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

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

ѕ комплексная связь между существующими системами в ИТ-инфраструктуре компании;

ѕ обеспечение надежной передачи информации между системами;

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

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

Таблица 1. Эффекты от внедрения ESB в общую ИТ-инфраструктуру компании

Данные результаты анализа показывают, что компании IBM, ORACLE являются лидерами на рынке интеграционных решений. Платформы IBM, ORACLE имеют широкий диапазон внедрений во всех сферах деятельности в Европе и на территории РФ.

Корпоративная интеграционная подсистема на базе IBM WebSphere Business Integration Message Broker [28] отвечает за выстраивание корпоративной интеграционной подсистемы (КИП), компоненты КИП могут быть модифицированы под конкретные задачи компании, внедряющей решение в зависимости от существующей ИТ-инфраструктуры компании.

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

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

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

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

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

Ядром решения является программное обеспечение Websphere Business Integration Message Broker, которое обеспечивает обработку передаваемой от приложения к приложению информации и ее интеллектуальную маршрутизацию.

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

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

К этому же классу продуктов, называемому ESB, относятся известные на рынке продукты TIBCO, E-mule, и многие другие.

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

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

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

Чтобы следовать принципу повторного использования, потребуется выстроить методологию и прозрачный подход в части управления ИТ, начиная с инфраструктурного уровня и заканчивая пользовательским уровнем. Примерами следов такой гармонизации могут стать появление корпоративной модели данных (Enterprise Data Model, EDM), корпоративной модели сервисов (Enterprise Service Model, ESM), корпоративной модели ролей (Enterprise Role Model, ERM) и т.д. Каждая из этих моделей гармонизирует и унифицирует свою функциональную область. Любое новое изменение обязательно должно проходить контроль наличия места для него в описанной модели [1].

Вторым важным принципом адаптивной архитектуры является уход от системного программирования. Архитектурная зависимость от таких методов разработки делает развитие дорогим и немасштабируемым. На смену уходящему подходу пришли платформы и CASE-средства.

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

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

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

3.2 Видение архитектуры ИС компании

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

ѕ аналитика;

ѕ ERP (управление ресурсами предприятия);

- бухгалтерия;

- бюджетирование и стратегическое планирование;

- закупки;

- логистика;

- Human Recourses;

- документооборот;

ѕ Billing (ведение тарифных планов, организация расчетов, продукты);

ѕ CRM (взаимоотношения с Клиентами СаД Center, маркетинг);

- взаимодействие с Клиентом;

- контакт-центр;

- Campaign Management (и подсистемы Interact, Optimize);

- BPM;

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

ѕ диспетчеризация оборудования.

Данная структура является классической, но далекой от российских корпораций (крупных корпораций со сложной ИТ-архитектурой). На рисунке 19 представлено описание текущей ситуации в ИТ-ландшафте компании.

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

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

3.3 Оценка проекта Campaign Management при использовании предложенного варианта

Прогнозируемая оценка проекта после реализации единой шины данных как прослойки между всеми компонентами ИТ-ландшафта компании выполняется по методу оценки на основе Use-case points на примере проекта Campaign management.

Методология описана в приложении 1. На этапе оценки акторов видно различие от оценки без ESB. Простой актор использует систему по предопределенному API (REST, SOAP, dll), средний использует более сложный и гибкий API, комплексный в большинстве случаев означает взаимодействие с конечным пользователем (см. таблицу 2).

Таблица 2. Оценка акторов

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

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

Также в качестве транзакта можно использовать количество объектов в БД, изменяемых в рамках одного варианта использования. В этом случае ранжирование будет иметь такой вид: простой - 1 объект, средний - 2 объекта, комплексный - больше или равно 3 объекта.

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

Таблица 3. Оценка технических факторов

На этапе оценки внешних факторов производится расчет коэффициента для оценки организационных рисков при разработке. В данном случае при внедрении единой интеграционной шины оценка внешних факторов наоборот показывает увеличение затрат, поскольку в команду разработки будут требоваться более квалифицированный персонал, особенно это касается архитектора, разрабатывающего технические решения совместно с руководителем группы. К примеру, в показатель «Сложности, связанные с языком программирования» запишется значение более высокое по сравнению с оценкой до внедрения ESB, что вызвано необходимостью владения не только pl/sql (основной язык разработки для решения задач проекта Campaign Management), но и JavaSrcript.

В результате подсчитываются итоги. Итог = 337,49 (человеко-часы каждого разработчика (7 человек)). После получения оценки необходимо правильно оценить количество часов на один поинт. Существуют классические рекомендации, равные 20-28 часов, однако в действительности оценка может отличаться, в зависимости от следующих факторов:

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

ѕ готовность оценивать тестирование, требования и менеджмент таким же образом.

Таким образом, получена разница в примерно в 91 час. Стоит отметить, что при более точном планировании можно выявить дополнительные факторы, которые окажу существенное влияние на человеко-часы при реализации после внедрения ESB.

Заключение

По завершении работы получены следующие результаты:

ѕ приведено обоснование необходимости создания гибкого метода интеграции новых систем (чаще всего инструментов BI) в общую ИТ-архитектуру компании. Метод интеграции сторонних систем анализа и обработки данных в существующую ИС архитектуру компании позволяет:

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

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

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

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

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

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

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

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

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

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

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

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

интеграция архитектура автоматизированный управление

Библиографический список

· Инвентарный № ОФЭРНИО 11394-Средства тиражирования данных METAS Replication.

· Инвентарный № ОФЭРНИО 11378-Программное ядро MDK Suite CASE-системы METAS.

· Инвентарный № ОФЭРНИО 11379-Система интеграции распределенных приложений Simple BizTalk Server (SBTServer).

· Интеграция информационных систем предприятия. Взаимосвязь информационных систем предприятия. НОУ Интуит.

· Когаловский М.Р. Методы интеграции данных в информационных системах / М.Р. Когаловский // Институт проблем рынка РАН, М. - 2010 - С. 9.

· Когаловский М.Р. Системы доступа к данным, основанные на онтологиях // Второй симпозиум «Онтологическое моделирование», Казань, октябрь 2010.

· Кочергов Д. Шпаргалка финансиста // Экономика бизнеса №46 (9260)

· Кузнецов Д.П. Метод и средства интеграции онтологий разнородных источников данных в автоматизированных системах управления промышленных предприятий: Автореф. дис. … канд. техн. наук: 05.13.06; [Место защиты: ВлГУ]. Вологда: ВоГТУ, 2013.

· Лазарев А. В. Ставка дисконтирования с учетом риска и методы ее определения [Текст] / А. В. Лазарев, А. В. Пострелова // Молодой ученый. - 2013. - №6. - С. 373-376.

· Ложечкин А. Интеграция приложений электронной коммерции с использованием BizTalk Server. М.: Издательский дом «Русская редакция», 2001.

· Манагаров Р. Обзор методов расчета ставки дисконтирования // Библиотека управления

· Мусаев А.А. Интеграция автоматизированных систем управления крупных промышленных предприятий: принципы, проблемы, решения. / А.А. Мусаев, Ю.М. Шерстюк // Материалы журнала «Автоматизация в промышленности» №10, М. - 2003 - с. 40-45.

· Ступников С.А. Формирование базы метаинформации на основе спецификаций канонической модели // С.А. Ступников, Л.A. Калиниченко// ИРИ РАН - С.8.

· Теленик С.Ф. Каталогизация и интеграция разнородных информационных ресурсов [Текст] // Молодой ученый. - 2013. - №5. - С. 176-179.

· Хмельнов А.Е. Язык описания данных FlexT: использование динамических типов для описания статических данных / Институт Динамики Систем и Теории Управления СО РАН.

Размещено на Allbest.ru