Интеграционное решение как важнейший компонент стратегии развития компании

Интеграционное решение как важнейший компонент стратегии развития компании ЛЕКЦИЯ 1 по дисциплине «ИНТЕГРАЦИЯ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ» Доцент кафедры «Бизнес-информатика» к.т.н., доц. Морозова О.А. Москва 2017 План лекции 2  АКТУАЛЬНОСТЬ ЗАДАЧИ ИНТЕГРАЦИИ  ЭВОЛЮЦИЯ ПОДХОДОВ К ИНТЕГРАЦИИ      ИНФОРМАЦИОННЫХ СИСТЕМ МЕТОДОЛОГИЯ ОТКРЫТЫХ СИСТЕМ ЦЕЛИ И ЗАДАЧИ ИНТЕГРАЦИИ ТИПЫ ИНТЕГРАЦИОННЫХ РЕШЕНИЙ ПРОБЛЕМЫ ИНТЕГРАЦИИ КРИТЕРИИ ВЫБОРА ИНТЕГРАЦИОННОГО СЦЕНАРИЯ Актуальность задачи интеграции 3 Условие успешного развития компании сегодня - создание ИТ инфраструктуры, в которой интегрированы вычислительные, информационные и коммуникационные ресурсы. 2. На предприятия за годы работы складывается определенная ИТинфраструктура. Десятки приложений для автоматизации отдельных видов деятельности, бизнес-процессов и решения аналитических задач. (зоопарк решений). 1.  Почему так происходит?    3. Невозможно подобрать ИКИС, охватывающую все бизнес-функции предприятия, учитывающую отраслевую и региональную специфику. Для каждой бизнес-функции выбирается «оптимальное решение». Разработчики ПО не заинтересованы в разработке универсальных решений. Необходимо поддерживать общие бизнес-процессы (распределенные бизнес-процессы охватывают различные подразделения компании внешних партнеров и заказчиков). Актуальность задачи интеграции 4 3. Необходимо организовать совместный доступ к данным и совместное использование данных.      Разнородные распределенные данные. Противоречивые источники информации в приложениях. Проводить синхронизацию данных сложно и дорого. Низкое качество данных. Проблема трех V (Volume-Velocity-Varaity) В процессе слияния и поглощения компаний наследуются новые системы. Отдельные департаменты приобретают ПО для своих локальных задач. 5. Сложно поддерживать преобразование бизнеса. 6. Проблема сохранения инвестиций в ИТ. 4. Цена вопроса 5  По оценке компании Gartner Group на каждый доллар, который организации тратят на разработку и внедрение прикладных информационных систем, приходится еще от пяти до двадцати долларов затрат, связанных с интеграцией с другими системами.  Затраты на интеграцию CRM-решения составляют до 50% стоимости проекта внедрения. Эволюция подходов к интеграции ИС 6  60-70 годы ХХ века - корпоративные приложения обеспечивают выполнение очень простых функций, основное назначение автоматизация выполнения повторяющихся задач. Основная задача – автоматизация отдельных процессов или их составляющих  80-е годы - начали понимать значение и необходимость интеграции приложений. Попытки перепроектировать используемые приложения, в целях их интеграции. Зарождение модульной архитектуры ИС  90-е годы - единственно верный путь комплексной автоматизации – создание универсальной ИС (от одного производителя) - ИКИС. Эволюция подходов к интеграции ИС 7  ИКИС основана на единой программно-аппаратной платформе и общей базе данных.  В ИКИС отдельные функциональные подсистемы взаимосвязаны на основе единого технологического процесса обработки информации.  Для функционирования ИКИС необходимо организовать на предприятии локальную вычислительную сеть (ЛВС).  ERP системы - «система управления всеми бизнес-процессами предприятия, увязывающая функции отдельных подразделений с движением финансовых и товарных потоков по всей технологической цепочке управленческих процедур»  Задача ERP-системы - интегрировать все подразделения и функции корпорации в единой информационной системе.  Охватывает все стороны производственной и коммерческой деятельности : производство, планирование, управление договорами, материальнотехническое снабжение, финансы, бухгалтерия, управление кадрами, сбыт, управление запасами. Эволюция подходов к интеграции ИС 8  Основа ERP - единая база данных, которой пользуются в равной степени все подразделения компании.  Возникает инфраструктура электронного обмена данными как между подразделениями или предприятиями корпорации, так и между корпорацией и ее поставщиками и потребителями. Концепция ERP до настоящего времени не стандартизирована. Определение ERP системы - «система управления всеми бизнес-процессами предприятия, увязывающая функции отдельных подразделений с движением финансовых и товарных потоков по всей технологической цепочке управленческих процедур». Эволюция подходов к интеграции ИС. Проблемы ERP 9  Любая ERP-система не в состоянии решить все задачи, стоящие перед      предприятием (требуется приобретение дополнительного модуля или разработка собственного приложения + проведение интеграции). Установка новой версии одного из приложений, входящих в ERP-систему, требуется обновление и других модулей. Всегда есть унаследованные приложения. Существующие приложения эксплуатируются во время внедрения ERP-модулей (необходима интеграция). Слияния и поглощения компаний являются источником возникновения интеграционных проблем: часто в компаниях используются ERP-системы от различных поставщиков. Проблема взаимодействия с внешними контрагентами, клиентами, развитие электронной коммерции и т.д. Необходимость автоматизации новых направлений деятельности (электронные карты, электронные торговые площадки, мобильная связь, облачные сервисы и др.)  ИТОГ: возникновение рынка специализированных систем Эволюция подходов к интеграции ИС. Современная ИТ-инфраструктура 10  ERP (предприятия), АБС (банки) теряют лидерство в ИТ- инфраструктуре  Конкурентное преимуществом специализированного ПО явилась специализация, основанная на глубоком знании отдельных процессов и технологий  Усложнение ИТ-инфраструктуры, возникновение многочисленных связей Моно и мульти-вендорная стратегии развития ИТ Подход «best-of-bread» Системы middleware первого поколения 11 Обеспечивали уровень передачи сообщения (структурированный набор параметров, описывающих определенный тип транзакции). Современные промышленные системы класса middleware 12   Сложное ПО, способное обрабатывать сообщения на базе универсальных форматов и обеспечивать многоканальную передачу сообщений между всеми бизнес приложениями. Основные компоненты:   Интеграционный брокер, играющий роль сервисной шины (выполняет функции переформатирования данных, маршрутизации сообщений, управления транзакциями, мониторинга и контроля взаимодействия приложений). Набор адаптеров, которые позволяют различным приложениям подключаться к брокеру. Методология открытых систем и проблема интеграции 13 Проблема стыковки различных программных компонентов. Методология открытых систем разработана для:  сохранения вложенных ранее инвестиций при построении информационных систем (ИС) на различных аппаратных и программных платформах,  обеспечения взаимосвязи систем,  переносимости прикладного программного обеспечения и данных. Стандарты, обеспечивающие открытость ПО разрабатываются и поддерживаются рядом международных организаций, в том числе:  Совместным техническим комитетом ИСО и МЭК (ISO/IEC/JTC 1) ИСО/МЭК/СТК 1 "Информационные технологии";  Европейской рабочей группой по открытым системам (EWOS);  Национальным институтом стандартов и технологий США (NIST).  Основная идея - выделение в системе интерфейсной части, обеспечивающей связь с другими системами или подсистемами. Для объединения систем достаточно знать параметры стандартизованного интерфейса связываемого объекта. Основные нефункциональные требования к открытым системам 14  Открытые системы – это системы, в которых реализован "исчерпывающий и согласованный набор международных стандартов информационных технологий и профилей функциональных стандартов, которые специфицируют интерфейсы, сервисы и поддерживаемые форматы данных, чтобы обеспечить интероперабельность и мобильность приложений, данных и персонала". расширяемость (или масштабируемость) - возможность добавления новых функций ИС или изменения некоторых уже имеющихся функций без изменения остальных функциональных частей ИС, возможность сохранения работоспособности системы при изменении значений параметров, определяющих технические и ресурсные характеристики системы и/или среды;  мобильность (или переносимость) - обеспечивается возможность переноса программ и данных при модернизации или замене аппаратных платформ ИС, а также возможность использования опыта людей, пользующихся данной ИТ, без их переучивания при изменении ИС;  интероперабельность - обеспечивается способность к взаимодействию данной ИС с другими ИС;  Методология открытых систем поддерживается крупными компаниями-разработчиками и производителями средств вычислительной техники и средств телекоммуникаций (Digital, Hewlett-Packard, IBM, Sun Microsystems и др.) Сущность методологии открытых систем 15 Две группы стандартов: • стандарты прикладных программных интерфейсов(Application Program Interface (API) Standards). Эти стандарты определяют взаимодействие прикладного программного обеспечения с компьютерной системой (прикладной платформой) и предназначены в основном для обеспечения переносимости приложений. • стандарты внешнего окружения (External Environment Interface (EEI) Standards). Эта группа стандартов определяет взаимодействие информационной системы с ее внешним окружением и предназначена для решения проблем интероперабельности систем, повторного использования программного обеспечения и переносимости данных. Цели и задачи интеграции 16 Интеграция приложений – это стратегический подход к объединению информационных систем, обеспечивающий возможность обмена информацией и поддержания распределенных бизнес-процессов. Интеграция информационных систем дает предприятию такие конкурентные преимущества как: • ведение бизнеса в режиме реального времени, с использованием событийно-управляемых сценариев. • владение достоверной, полной и своевременно полученной информацией. Задача интеграции - обеспечение эффективного, надежного и безопасного обмена данными между различными программными продуктами, изначально не предназначавшимися для совместной работы. Движущие силы интеграции 17 Потребности бизнеса:      Электронный бизнес – интеграция унаследованных ИС, поддерживающих ключевую функциональность с Web-приложениями (Web-сервисами и порталами) с целью получения доступа к бизнес-функциям через интернет; Управление цепями поставок – интеграция разрозненных систем управления заказами, MRP-систем, систем календарного планирования, систем транспортного менеджмента и др. с целью прямого обмена информацией между покупателями и поставщиками в режиме реального времени; Управление взаимоотношениями с клиентами – получение единого консолидированного представления о клиенте путем объединении данных о клиенте, распределенных между несколькими изолированными приложениями (интеграция клиентских баз данных, call-центров, интернет -сервисов). Внедрение ERP – интеграция модулей ERP-систем, поддерживающих базовую функциональность со специализированным программным обеспечением, используемым организацией; Электронное правительство – интеграция унаследованных back-end систем с front-end Web-приложениями, организация обмена данными между правительственными учреждениями; Движущие силы интеграции 18      Самообслуживание клиентов – возможность клиентов самостоятельно выполнять действия, традиционно выполняемые обслуживающим персоналом, требует интеграции пользовательских приложений с back-end системами. Business Intellegence – сбор данных из различных приложений и источников данных в хранилище данных с целью обработки и анализа данных. Управление знаниями - обеспечение доступа в режиме реального времени к корпоративному контенту, распределенному между многочисленными источниками, с целью управления знаниями в масштабах предприятия; Облачные технологии – интеграция существующих бизнес-приложений с облачными приложениями и сервисами. Аутсорсинг бизнес-процессов – интеграция с информационными системами партнеров. Бизнес –выгоды от реализации интеграционного проекта 19 • Улучшение качества поддержки и обслуживания клиентов • Автоматизация бизнес-процессов • Уменьшение производственного цикла • Сокращение количества ошибок обработки данных • Прозрачность процессов • Уменьшение стоимости транзакций • Оптимизация логистических процессов • Более тесное взаимодействие с бизнес-партнерами • Быстрое внедрение новых бизнес-сервисов • Сохранение инвестиций в ИТ Типы интеграционных решений 20 По принадлежности объединяемых приложений выделяют:  Интеграцию корпоративных приложений в пределах предприятия (Application-to-Application Integration– A2A) – автоматический событийноуправляемый обмен информацией между приложениями и системами, действующими на предприятии или в организации;  Интеграцию приложений между предприятиями (Business-to-Business Application Integration - B2B) - автоматический событийно-управляемый обмен информацией между приложениями или системами нескольких взаимодействующих предприятий или организаций. Вертикальная и горизонтальная интеграция 21 По уровням управления  горизонтальная интеграция - интеграция информационных систем или приложений, относящихся к одному уровню управления. Пример является автоматизация управлением цепями поставок (различные приложения или компоненты обеспечивают полный цикл логистических операций)  вертикальная интеграция - интеграция приложений и систем, находящихся на различных уровнях информационной пирамиды. Пример – сбор данных операционных систем в единое корпоративное хранилище данных с целью их последующего использования для анализа, управления и получения консолидированной отчетности. Проблемы интеграции 22 Технические проблемы:      Риск задержки и потери информации, вызванный ненадежностью сетей передачи данных (обеспечивая связь между отдельными частями интеграционного решения необходимо передавать информацию между устройствами по телефонным линиям, локальным сетям, через маршрутизаторы, общедоступные сети и каналы спутниковой связи). Недостаточная скорость передачи данных (объективно время доставки данных через компьютерную сеть всегда больше времени вызова локального метода, поэтому интеграционное решение всегда работает медленнее локального приложения). Необходимость учитывать все различия между приложениями (приложения написаны на разных языках программирования, разные платформы, разный формат данных). Ограниченный контроль над интегрируемыми приложениями, представляющими собой, например, унаследованные коммерческие приложения с закрытой структурой БД или плохо документированные системы, разработанные ИТ-департаментом. Необходимость поддерживать интеграционное решение, т.е. адаптировать его к изменениям в интегрируемых приложениях. Зачастую изменения в одной системе влекут за собой непредсказуемые изменения в других системах. Проблемы интеграции 23 Методологические проблемы: Отсутствие корректного формата или семантического слоя для слияния двух и более несопоставимых наборов данных. Устранение семантических различий между приложениями – одна из наиболее сложных и неформализуемых задач интеграции.  Необходимость наличия методологии для документирования технических аспектов интеграции (определение записей, структур данных, интерфейсов и потоков данных в масштабах всей организации)  Необходимость определения правил и методов согласования данных во всех интеграционных проектах (правил устранения семантического диссонанса).  Проблемы интеграции 24 Организационные проблемы: Недостаток доверия к корректности информации  Интеграция приложений в большинстве случаев влечет за собой пересмотр корпоративной политики. Объединение ИС (например, CRM-системы и системы бухгалтерского учета) требует изменений в порядке взаимодействия между использующими эти системы отделами (отделом маркетинга и бухгалтерией)  При интеграции ключевых бизнес-функций компании, ее деятельность становится зависимой от функционирования интеграционного решения, сбой в работе которого может принести компании существенные убытки (ошибочные платежи, потерянные заказы и т.д..).  Критерии выбора интеграционного решения 25  Степень связывания приложений – зависимости между интегрируемыми приложениями должны быть сведены к минимуму (реализация принципа слабой связи между приложениями). Изменение функциональности или сбой в работе одного приложения может привести к нарушению допущений и потере работоспособности интеграционного решения.  Простота поддержки интеграционного решения – следует стремиться минимизировать изменения, вносимые в объединяемые приложения, а также объем кода, необходимого для интеграции.  Объем данных – выбор способа интеграции зависит от объема передаваемых данных. Следует учитывать, что несвоевременная доставка или потеря данных приведет к рассинхронизации приложений.  Стоимость решения - отдельные интеграционные решения требуют применения специального программного обеспечения (ПО класса middleware), что существенно увеличивает стоимость проекта интеграции. С другой стороны, более «бюджетная» разработка проекта интеграции «с нуля» намного более рискованна и может свести усилия разработчиков к «изобретению велосипеда». В каждом проекте инструмент интеграции необходимо выбирать, исходя из масштабов и сроков проекта, задачи интеграции, наличия квалифицированных кадров, бизнес-требований.. Проблемы интеграции 26 Отличие интеграционных решений от распределенных  Взаимодействие компонентов в РС построено при принципу «сильной связи» (ни один из уровней приложения не может функционировать без остальных). Взаимодействие между уровнями синхронно. Пользователи системы – это люди (поэтому важен быстрый отклик).  Интеграция – это налаживание слабой связи между независимыми приложениями. Каждое интегрированное приложение выполняет свои функции и обращается к другим приложениям для получения дополнительной функциональности. Взаимодействуют асинхронно, не дожидаясь ответа (отказ от временных ограничений). Степень связанности приложений 27 Сильная связь: Интеграционная логика распределена между ИС и часто неотделима от их функциональности Системы обращаются напрямую к внутренним объектам друг друга Проблемы:      Разработка и поддержка нескольких связок с каждой ИС. Один и тот же функционал реализовывается многократно Изменения в одной системе непредсказуемо влияют на работоспособность других ИС (интеграционное тестирование) При любых изменениях необходимо привлекать разработчиков всех ИС (даже, если изменения бизнес-логики не требуется) Сложно выявить причину сбоя Саботаж разработчика (интеграция с решением конкурента) Степень связанности приложений 28 Слабая связь В слабосвязанных системах интеграционная логика выносится за рамки прикладной системы и реализуется в специализированном интеграционном ПО. В прикладных системах реализуются внешние интерфейсы для доступ к ним извне. Одна из ИС может быть заменена без внесения изменений в другие системы. Пример сильной связи 29 Webприложение Реквизиты перевода Финансовая система TCP/IP Межплатформенная интеграция Сокет String hostName = “my.bank.com"; //Задание DNS-имени удаленного компьютера int port = 80; IPHostEntry hostInfo = Dns.GetHostByName(hostName); //Преобразование имени удаленного компьютера в IP-адрес IPAddress address = hostInfo.AddressList[0]; IPEndPoint endpoint = new IPEndPoint(address, port); Socket socket = new Socket(address.AddressFamily, SocketType.Stream, ProtocolType.Tcp); socket.Connect(endpoint); byte[] amount = BitConverter.GetBytes(1000); //Преобразование данных в поток байтов byte[] name = Encoding.ASCII.GetBytes("Joe"); int bytesSent = socket.Send(amount); bytesSent += socket.Send(name); socket.Close();  ЧТО ПЛОХО? • Связываемые системы должны иметь одинаковое внутреннее представление целых чисел (32 или 64-бит), и одинаковый порядок следования байтов (прямой или обратный) • Компьютер должен иметь неизменяемый адрес • Интегрируемые приложения должны быть доступны в одно и то же время, поскольку протокол TCP/IP является протоколом с установкой соединения • Использование соглашения о формате данных Преимущества слабосвязанных интеграционных решений 30 Формализация взаимного влияния систем (легко отследить изменения в ИС) Уменьшается риск сбоя систем в промышленной эксплуатации (важно для бизнес-критичных приложений). Локализация ошибок. Четко определенный формат взаимодействия позволяет однозначно локализовать ошибки, определить их причину (нарушение формата взаимодействия или внутренний сбой одной из систем) и ответственность за их исправление. • • • Снятие интеграционных задач с разработчиков прикладных систем • Повторное использование интерфейсов (разными ИС в разных процессах) Сокращение затрат на разработку Использование специальных интеграционных инструментов для технологических задач • • • • Сокращается время на обнаружение сбоя. Уменьшаются трудозатраты при локализации сбоя. Устраняется необходимость привлечения разработчиков ПО для обнаружения сбоя. Увеличивается прозрачность при определении ответственности за сбой программного комплекса. Возможность предприятия самостоятельно строить\менять интеграционное решение Уменьшаются сроки проектов (внедрение и интеграция могут происходить параллельно) Уменьшается трудоемкость разработки и сопровождения интеграционных решений. С прикладной системы снимается нагрузка по решению интеграционных задач. Сценарии интеграции информационных систем ЛЕКЦИЯ 2 по дисциплине «ИНТЕГРАЦИЯ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ» Доцент кафедры «Бизнес-информатика» к.т.н., доц. Морозова О.А. Москва 2017 2  Не существует универсального подхода к интеграции приложений,  Не существует единственного варианта интеграционного решения  Можно найти оптимальный в рамках конкретного интеграционного сценария способ связывания приложений. Критерии выбора интеграционного решения 3  Степень связывания приложений – зависимости между интегрируемыми приложениями должны быть сведены к минимуму (реализация принципа слабой связи между приложениями).  Простота поддержки интеграционного решения – следует стремиться минимизировать изменения, вносимые в объединяемые приложения, а также объем кода, необходимого для интеграции.  Объем данных – выбор способа интеграции зависит от объема передаваемых данных.  Стоимость решения - отдельные интеграционные решения требуют применения специального программного обеспечения (ПО класса middleware), что существенно увеличивает стоимость проекта интеграции. С другой стороны, более «бюджетная» разработка проекта интеграции «с нуля» намного более рискованна. Шаблоны интеграции 4  Систематизируют знания в области интеграции ИС.  Не стандартизованы.  Наиболее известны:    Integration Patterns от компании Microsoft, Patterns: Implementing an SOA Using an Enterprise Service Bus. IBM Хоп Г., Вульф Б. Шаблоны интеграции корпоративных приложений.: Пер с англ. - М.: ООО «И.Д. Вильямс» (только обмен сообщениями). Классификация шаблонов интеграции 5  Охватывают следующие аспекты интеграции:  Архитектура промежуточного слоя (middleware).  Способы связывания приложений.  Топология интеграционных решений. Взаимосвязь шаблонов с основными характеристиками интеграционных решений 6 Цель интеграции Шаблоны архитектуры промежуточного слоя • Единое представление • Агрегация сущностей • Интеграция процессов • Интеграция, корпоративных данных • Распределенный бизнес-процесс • Единая точка доступа к данных из нескольких ориентированная источников портал на Взаимосвязь шаблонов с основными характеристиками интеграционных решений 7 Уровень связывания Шаблоны связывания приложений приложений • База данных • Интеграция данных • Уровень бизнес-логики • Функциональная интеграция • Уровень пользовательского интерфейса • Презентационная интеграция Взаимосвязь шаблонов с основными характеристиками интеграционных решений 8 Способ взаимодействия Шаблоны топологии приложений интеграционного решения • • Точка-точка • Брокер сообщений • Шина сообщений • Публикация-подписка Взаимодействие один-кодному • Взаимодействие через центральный «коммутатор» • Открытое взаимодействия • Взаимодействие ко-многим один- Иерархия шаблонов 9 Реальные интеграционные решения, как правило, основываются на использовании нескольких шаблонов (представляют собой гибридные решения) Архитектура промежуточного слоя 10 Шаблон Решаемая проблема промежуточного слоя Агрегация Как сущностей распределенные между несколькими репозиториями. Интеграция Как управлять исполнением распределенного бизнес-процесса, процессов если приложениям отдельные эффективно бизнес-функции использовать выполняются данные, разными приложениями. Портал Как конечные пользователи могут эффективно решать задачи, требующие доступа к информации, распределенной между несколькими приложениями. Агрегация сущностей 11  Наиболее доступный и распространенный вид интеграции.  Необходимо иметь единое согласованное в масштабах организации (отрасли) представление ключевых сущностей, например, таких как «Клиент», «Заказ», «Счет», «Продукт» и т.п.  Сложности:       Корпоративные системы, как правило, используют разные информационные модели для описания одной и той же сущности Семантический диссонанс между данными их разных систем. Один и тот же элемент данных из разных систем может представлять разную информацию. Возможно несовпадение данных для одного и того же экземпляра сущности. Репозитории могут содержать ошибочные данные. При проведении синхронизации данных между несколькими репозиториями может быть нарушена ссылочная целостность. Приложение-потребитель может затребовать данные, хранящиеся в разных репозиториях Агрегация сущностей 12  Промежуточный слой, обеспечивает единое логическое представление сущностей в масштабе организации, физически связанкак с репозиториями данных, так и с приложениями-потребителями информации. Агрегация сущностей 13 Включает два основных этапа:   Определение единой в рамках предприятия модели данных, которая обеспечит унифицированное представление сущностей. Установление физических связей между компонентами интеграционного решения.  В разных репозиториях используются разные схемы данных для одной и той же сущности. Задача промежуточного слоя гармонизировать различия между этими схемами,.  Промежуточный слой должен:    Удовлетворять потребностям всех интегрируемых приложений; Определять каноническую схему данных для всех сущностей, используемых несколькими приложениями; Поддерживать трансформации схем каждого источника данных в каноническую схему данных Каноническая схема данных 14 Архитектурные подходы к агрегации 15  Репликация – это ориентированная на обработку наборов данных технология преобразования, предназначенная для решения задач миграции, консолидации, создания хранилищ данных. Достоинства репликации 16  Возможность использования разнородных данных любого качества         (поскольку на этапе трансформации могут быть выполнены все необходимые процедуры проверки, очистки, обогащения данных). Хорошая масштабируемость решений. Наличие четкой методологии интеграции. Асинхронный обмен данными. Не требует изменений в интегрируемых ИС. Эффективный доступ к интегрируемым данным за счет отделения приемника от источника. Слабая связь между интегрируемыми системами. Возможность повторного использования объектов и преобразований (снижает затраты на разработку и поддержку). Относительно низкая стоимость. Наличие доступных инструментов (программного обеспечения класса middleware). Архитектурные подходы к агрегации 17  Федерация информации - процесс извлечения данных из различных источников в режиме реального времени и представление ее в едином унифицированном виде. Достоинства федерации информации 18  Возможность интеграции структурированных и     неструктурированных данных из многих источников. Доступ к данным в режиме реального времени (по требованию). Поддержка процессов чтения и записи данных. Возможность преобразования данных для бизнес-анализа и обмена информацией. Наличие доступных инструментов (программного обеспечения класса middleware). Критерий сравнения Репликация Поток данных В одну сторону Федерация от источника к В обе стороны приемнику Перемещение данных Задержка Преобразование, Управляется процессом. запросом SQL День-неделя-месяц Реальное время очистка, Лучшее использование метаданных в процессе Транспорт Объемы По расписанию – пакетная загрузка. В момент запроса. Управляется Обычно Среднее высокая степень повторного Преобразования встроены использования объектов и процессов. представления и объекты БД FTP, прямое соединение с БД Прямое соединение с БД обрабатываемых Очень большие (миллионы записей) данных Средние (сотни в тысяч удаленных записей) Сложность преобразований Любая Преобразования, которые можно описать на SQL Поддержка мониторинга Ограниченная событий Можно улучшить с помощью технологии Зависит возможностей триггеров в источнике. захвата изменений в источнике Контроль потоков работ от По расписанию. Обработка ошибок Нет 19 Агрегация сущностей 20 Преимущества Недостатки • • Обеспечивает унифицированное представление основных • доступ вопросу к информации, • существующими приложениями. консенсуса между между унифицированного представления данных, • Уменьшает семантический диссонанс Требует подразделениями (организациями) по (отраслевых) данных, Облегчает дополнительный архитектурный слой, корпоративных • Создает Требует подключения существующих приложений к промежуточному слою. Интеграция процессов 21  Основная задача интеграции процессов - координация бизнес-функций, поддерживаемых различными информационными системами. Интеграция процессов 22  Решение задачи интеграции бизнес-процессов требует построения модели распределенного бизнес-процесса, а также создания отдельного компонента управления распределенным бизнеспроцессом (process manager), который контролирует параллельно выполняемые экземпляры процесса и обеспечивает взаимодействие с существующими приложениями для выполнения отдельных шагов в соответствии с заданной моделью Интеграция процессов 23 Компонент Назначение Модель процесса Определяет последовательность шагов для выполнения бизнес-функции Компонент Интерпретирует модель процесса. Связывает шаги управления процесса, определенные в модели с функциями распределенным приложений. бизнес-процессом Управляет экземплярами (process manager) мониторинг текущего процесса, состояния запущенных экземпляров процесса. Приложение ведет Выполняет определенную бизнес-функцию Иерархическая интеграция бизнес-процесов 24  Process manager предоставляет интерфейс, с помощью которого бизнес- процесс, описанный в виде модели, может быть запущен пользователем или другим приложением. Такой интерфейс реализован либо как интерфейс пользователя, либо как API, доступное любым внешним приложениям. Запуск бизнес-процесса через API для внешнего приложения не отличим от вызова API отдельного приложения. Интеграция процессов 25 Преимущества • • Недостатки Возможность бизнес-процесс • моделировать независимо от реализации бизнес-функций. из-за Обеспечение соблюдения правил выполнения бизнес- параллельно выполняемых процессов. • процесса. • Возможное падение производительности слишком стоимость приложениями реализация приложения не решения. Поскольку компонента управления зависят от слоя управления бизнес-процессом). распределенным • Быстрая адаптация к любым бизнес-требованиям. достаточно сложная • Получение оптимальным вариантом данных оптимизации для анализа бизнес-процессов исполнением процесса централизованно, легко времени исполнения (т.к. этапов, типичных ошибках и т.п.). и управление выполняется собрать процесса выполнения и статистику его о отдельных числа Сложность и, как следствие, высокая Повторное использование функций, предоставляемых (существующие большого использование бизнес-процессом задача, является промышленных интеграционных платформ. Интеграция, ориентированная на порталы 26  Цель построения корпоративного портала – предоставление пользователям единой точки доступа ко всей корпоративной информации.  Корпоративный портал, как интеграционное решение, целесообразно использовать в том случае, если:   Отсутствует хорошее понимание бизнес-процесса, позволяющее построить его модель. Модель бизнес процесса не удается построить и в тех случаях, когда пользователи принимают решения, основываясь на информации, которую они получают (интеграция бизнес-процессов не может быть реализована). Существует непреодолимый семантический диссонанс между отдельными приложениями (интеграция данных невозможна или экономически нецелесообразна). 27  Построение портала сравнительно простая форма интеграции, ее достаточно легко реализовать, она оказывает минимальное влияние на связываемые приложения. Порталы 28 Преимущества • Оказывает Недостатки минимальное влияние на • интегрируемые системы. • Высокая интеграций предполагает Интегрировать приложения возможно за пользователя несколько дней (с учетом того, что многие принятия решения. предлагают платформы для разнообразные • построения корпоративных порталов). • процессов), реализации. вендоры скорость Неэффективен (по сравнению с Может быть использован в тех случаях, когда бизнес-процессы формализованы. не т.к. участие на этапе Существует риск совершения ошибки пользователем. Способы связывания приложений 29 Архитектура практически любого приложения может быть представлена тремя логическими уровнями:    Уровнем представления – это уровень пользовательского интерфейса, предназначенный для просмотра, ввода и корректировки данных, отправки на выполнение запросов конечными пользователями приложения. Уровнем бизнес логики - уровень, на котором сосредоточена бизнес-логика приложения, осуществляется управление потоками данных и организуется взаимодействие частей приложения. Уровнем данных - уровень, отвечающий за организацию доступа к данным и работу с базой данных, это уровень серверов БД.  «Стыковка» с промежуточной средой может быть осуществлена на каждом из логических уровней Способы связывания приложений 30  Интеграция на уровне данных – в промежуточный слой поступают данные из базы данных.  Функциональная интеграция – промежуточный слой интегрируется с уровнем бизнес-логики посредством API-интерфейсов и сервисов, предоставляемых приложением.  Интеграция на уровне представлений - в промежуточный слой извлекаются данные по технологии screen scraping (прочесывание экрана). Обеспечивает доступ к функциям приложения через пользовательский интерфейс путем моделирования ввода данных пользователем и чтения данных с экрана монитора. Интеграция данных 31  Одно приложение может использовать данные другого приложения, заимствовав их непосредственно из репозитория источника (базы данных или файла). Проблемы интеграции данных 32  Неоднородность источников данных на физическом уровне (могут      использоваться различные форматы файлов, одни источники могут быть вебсайтами, а другие – объектными базами данных и т.д.). Неоднородность источников данных на логическом уровне неоднородность используемых моделей данных для различных источников. Проблема семантического диссонанса. Постепенно усложняющийся процесс управления данными. Необходимо обрабатывать постоянно растущие объемы критически важных для бизнеса данных. Причем эти данные становятся все более разнообразными (имеют различный формат, поступают от различных партнеров и систем). Задача управления временем передачи данных, форматами и структурами, объемами становится все более нетривиальной. Увеличивается количество бизнес-запросов, требующих своевременной доставки информации потребителю. Причем доставка данных может осуществляться как в пакетном режиме, так и в режиме реального времени. Растут проблемы с качеством данных. Бизнесу необходимы достоверные данные. Необходимы инструменты аудита, мониторинга и очистки данных. Интеграция данных 33  С технической точки зрения интеграция данных - это самый простой тип интеграции.  может быть реализован с использованием FTP, командных файлов, различных утилит СУБД, ETL - инструментов и специальных сервисов интеграции данных.  Выбор способа связывания приложений на уровне данных определяется частотой изменения данных, сложностью преобразований данных, имеющейся инфраструктурой.  Выделяют три базовых шаблона связывания приложений на уровне данных:    Файловый обмен, Общая база данных, Копирование данных. Файловый обмен 34  Наиболее простой и исторически первый способ обмена данными между приложениями.  Технология основана на том, что одно приложение сохраняет (экспортирует) данные в файл, а другое приложение читает (импортирует) данные из файла. Обмен данными между приложениями осуществляется в пакетном режиме. Технология файлового обмена 35  Необходимо выработать соглашение об общем формате файлов (xml,      txt, xls,…). Задача преобразования данных в необходимый формат возлагается на модули импорта \ экспорта. Приложения должны использовать общее соглашение о правилах именования и расположении файлов. Приложение, создающее файл, должно обеспечить уникальность его имени. Необходимо определить регламент записи \ чтения файлов. Частота создания \ чтения файлов определяется бизнес-логикой процесса и технологическими ограничениями (доступность приложения, объем трафика, скорость передачи данных). Приложение, записывающее данные в файл, и приложение, читающее данные из файла не могут получить к нему доступ одновременно. Должен использоваться механизм блокировки доступа к файлу на время его записи. Должен быть использован механизм удаления \ архивирования старых файлов. Файловый обмен 36 Преимущества • • Универсальный способ для всех ОС, • Возможность поддерживается интегрируемых систем вследствие любыми языками низкой Не нужны сведения о внутренней информацией. приложения. Основная • частоты Нерациональное обмена использование задача – преобразование форматов ресурсов при слишком частой файлов. работе с файлами. Обеспечивает слабое связывание приложений. • рассинхронизации программирования. реализации • Недостатки Нет потребности специализированном дорогостоящем ПО. в связующем Общая база данных 37  Обеспечивает доступ нескольких приложений к данным одного физического репозитория. Общая база данных обеспечивает согласованность хранящейся в ней информации за счет того, что все приложения используют общую модель данных Общая база данных 38 Преимущества • Решается Недостатки проблема • семантического диссонанса БД для возможны сложности технического (может привести к снижению производительности нескольких приложений Сложно разработать единую схему БД. При создании унифицированной схемы бизнес-критичного приложения) и политического характера. • Есть программы (коммерческое ПО), которые работают со встроенной БД (работает только со встроенной схемой данных). • Возможно снижение производительности при увеличении числа обращений к общей БД, возрастает вероятность блокировки данных. • Доступ к БД по медленным линиям связи. • Изменения в приложениях могут повлечь за собой потребность в изменении структуры БД. • Изменения структуры базы данных требует согласования со всеми использующими её приложениями • Низкий уровень абстракции. Приложения работают не с логическими объектами, а с конкретными полями и записями. Копирование данных 39  использование копий БД для различных приложений, синхронизация данных обеспечивается при этом путем копирования данных из одной БД в другую. Цель интеграции заключается у организации такого управления копиями баз данных, которое минимизирует неизбежно возникающую рассинхронизацию данных. Копирование данных 40  «Издатель» – (сервер СУБД, имеющий эталонную копию данных) и «Подписчик» (сервер СУБД, нуждающийся в актуальной копии данных).  При выборе сценария копирования данных должны быть учтены следующие факторы:  Автономность – степень независимости, которую подписчики получают по отношению к получаемым данным (это может быть доступная для чтения или для изменения копия данных).  Допустимая задержка в обновлении данных – время, которое подписчик может обходиться без свежей копии данных.  Согласованность обновления данных – подписчик может получать копии транзакций в том же порядке, в котором они выполнялись на сервере издателя, или этот порядок не важен (или достаточно выборки из журнала транзакций издателя). Основные сценарии копирования данных 41  Один издатель, много подписчиков – существует центральная БД, содержащая актуальную копию данных и несколько подписчиков.  Много издателей, один подписчик – единственная центральная база данных, является подписчиком публикаций с нескольких серверов.  Много издателей много подписчиков – в этой модели каждый сервер СУБД одновременно является и издателем и подписчиком. Копирование данных 42 Преимущества • Недостатки репликации • Задержка обновления данных. встроенными • Доступ к БД по медленным Механизмы поддерживаются функциями всех промышленных • СУБД, • Достаточным условием копирования данных между различных линиям связи. производителей для СУБД (т.н. гетерогенная репликация) является совместимость с OLE DB. Необходимость в разрешении конфликтов, возникающих при изменении одной и той же записи в разных копиях БД. Функциональная интеграция 43  Это способ связывания приложений на уровне слоя бизнес-логики, при котором одно приложение использует функционал, инкапсулированный в другом приложении Функциональная интеграция 44  Для связывания приложений на уровне бизнес- логики необходимо выполнение двух условий:   Бизнес функция, которую необходимо использовать, существует в приложении-источнике. Зачастую API приложений не обеспечивает доступа к данным и функциям на том уровне детализации, который необходим для интеграции бизнес-функций. Возможен удаленный доступ к программному интерфейсу, инкапсулирующему нужную бизнес-функцию. Функциональная интеграция 45  3 базовых шаблона связывания приложений на уровне бизнес-логики:    Использование распределенных объектов, Интеграция, ориентированная на сообщения, Сервис-ориентированная интеграция. Использование распределенных объектов 46  Основан на стандартах объектно-ориентированного взаимодействия и использует технологии как .NET remoting, COM+ или CORBA. Объекты одного приложения взаимодействуют с объектами другого приложения, используется механизм виртуализации. Преимущества • Использование Недостатки хорошо известных • разработчикам технологий, применяемых • Сложная модель взаимодействия при приложений. построении распределенных • приложений. • Сильное связывание приложений. Целесообразно необходимо использовать, обеспечить если • интеграцию Плохо масштабируемые решения. Не все технологии обеспечивают межплатформенное приложений в режиме реального времени. взаимодействие. • Сложности поддержки. Интеграция, ориентированная на сообщения 47  Данный способ связывания приложений использует промежуточное программное обеспечение (систему обмена сообщениями), ориентированное на посылку сообщений. Обмен сообщениями позволяет наладить асинхронное взаимодействие между слабо связанными приложениями и гарантирует доставку сообщений от отправителя к получателю .  Основные понятия:   Сообщение – это наименьшая единица данных, которая может быть передана от отправителя к получателю. Каналы – представляют собой логические адреса в системе обмена сообщениями. Данные передаются между приложениями по каналам сообщений. Реализация каналов зависит от конкретной системы. Например, несколько логических каналов могут использовать один физический канал. Логические каналы скрывают детали конкретной реализации от приложений. Обмен сообщениями 48 Технология (5 основных этапов) 1. Создание. Отправитель создает сообщение, содержащее полезную информацию. 2. Отправка. Отправитель помещает сообщение в канал. 3. Доставка. Система обмена сообщениями доставляет сообщение с компьютера отправителя на компьютер получателя. 4. Получение. Получатель извлекает сообщение из канала. 5. Обработка. Получатель считывает полезную информацию. Существует два метода передачи сообщений от одной удаленной системы к другой – непосредственный обмен сообщениями и использование очередей сообщений.  Передача сообщения напрямую возможна только в том случае, если принимающая сторона готова принять сообщение в этот же момент времени.  Основная идея очереди сообщений – использование посредника (менеджера очередей сообщений), что позволяет работающим в различное время приложениям взаимодействовать в гетерогенных сетях и системах, и не требует одновременного подключения к сети. Очередь сообщений — это репозиторий, в котором хранятся сообщения в процессе их пересылки. Менеджер очереди сообщений передает сообщения из источника в место назначения. Таким образом, назначение очереди: маршрутизация сообщений и обеспечение гарантированной доставки сообщений получателю. Обмен сообщениями 49  Microsoft Message Queuing, IBM MQSeries, Sun Java System Message Queue.  Функции:     добавить сообщение в очередь; взять первое сообщение из очереди; проверить очередь на наличие сообщений; установить обработчик, вызываемый при появлении сообщения. Преимущества • • • Недостатки Время функционирования сервера может быть не связано со • Сложная временем работы клиентов (не требуется одновременной программирования доступности отправителя и получателя); (событийно-управляемая Гарантированная доставка сообщений от отправителя к модель получателю. создается Обеспечивается частный обмен небольшими порциями Считывать и обрабатывать заявки из множество событий, реагирующих на очереди могут входящие сообщения). Сложность несколько независимых компонент, что дает возможность отладки достаточно просто создавать устойчивые и масштабируемые интеграционных решений. • системы. • программирования, обработчиков данных (синхронизация данных приложений); • модель Возможна Сообщения могут быть преобразованы во время передачи доставке без уведомления отправителя и получателя (независимость Нарушения промежуточной среды от средства разработки компонент и сообщений. • используемого языка программирования). и Не тестирования задержка при информации. порядка подходит для передачи объемов данных. • Слабое связывание соединяемых приложений. больших • Возможность реализации различных способов доставки Снижает производительность. сообщений (рассылку всем получателям, группам, маршрутизацию). рассылку по • Сложность реализации синхронного обмена. 50 Сервис-ориентированная интеграция 51  SOA-интеграция стирает грань между интеграцией приложений и созданием распределенного компонентного приложения.  SOA — это парадигма для организации и использования распределенных возможностей, которые могут находиться в различных областях собственности.  Базовые понятия:   Сервис - это функция, являющаяся четко определенной, самодостаточной и не зависящей от контекста или состояния других сервисов. Процесс (бизнес-процесс) определяется как независимая от реализации сервисов логика их взаимодействия.  Выделение сервисов на основе функциональности приложений имеет смысл, только если они могут использоваться неоднократно и в различных контекстах. Сервис-ориентированная интеграция 52 Сервисы имеют четко определенные интерфейсы, инкапсулирующие ключевые правила доступа к ним. Сервисы строятся без каких-либо допущений о том, кто будет использовать или потреблять эти сервисы. Слабо связаны с потребителями. Интерфейс сервиса используется для связи поставщика и потребителя, он позволяет идентифицировать сервис, описать входную и выходную информацию. Реализация сервиса определяет функционал и бизнес логику сервиса, причем детали реализации полностью скрыты от потребителя. Потребители обращаются к прокси-объекту, который передает сообщения к поставщику сервиса. Базируется на открытых стандартах : SOAP,WSDL, UDDI, WS-BPEL, WS-CDL, BPMN 53 Функциональные типы сервисов 54  Сервисы данных – содержат логику обработки данных и     обеспечивают доступ к бизнес-данным, могут виртуально объединять данные из нескольких источников. Бизнес-сервисы – сервисы, реализующие элементарные бизнесфункции, которые не могут быть детализированы в рамках используемой бизнес-модели. Бизнес-сервисы более могут комбинироваться для создания высокоуровневых сервисов. Сервисы процессов – используются для управления бизнеспроцессом, оркестровки сервисов, используемых бизнес-процессом, мониторинга состояния бизнес-процесса. Сервисы взаимодействия – обеспечивают взаимодействие между приложениями и конечными пользователями. Сервисы доступа – предназначены для включения унаследованных приложений в SOA-архитектуру, могут менять логику бизнес-функции существующего приложения в целях оптимизации взаимодействия сервисов, могут использовать несколько функций унаследованного приложения для обеспечения семантических требований к сервису. Сервис-ориентированная интеграция 55  SOA-сценарий интеграции применим для:    Крупных территориально-распределенных компаний, решающих задачу построения единого информационного пространства, объединения унаследованных приложений и вычислительных ресурсов. Сервисных компаний, осуществляющих управление услугами и обеспечивающими их бизнес-процессами. Задачи вывода на рынок новых услуг, оказания услуг потребителям с гарантированным уровнем качества, модификации услуг требуют согласованной работы нескольких ИС, включая системы сторонних компаний. Управления процессами, требующими интенсивной обработки документов (задачи интеграция систем управления контентом, с САПР, системами управления проектами, отдельными модулями ERP). Преимущества • • Недостатки SOA основана на использование стандартов (WSDL, • Нецелесообразно BPEL, гомогенной UDDI), поддерживаемых большинством • • • • информационной поставщиком ИТ, что обеспечивает ее независимость от (например, задача интеграции платформ интегрируемых приложений, одного производителя). Исключается бизнес-функций • дублирование приложений. • использовать в среде ИС от Не подходит для эффективной работы в режиме реального времени. Обеспечивается слабое между • связывание Сложно правильно выделить сервисы для приложениями. получения Гибкая решения. интеграция приложений, позволяет быстро хорошо масштабируемого перестроить бизнес-процессы и адаптировать их к • Проблема изменившимся внешним условиям. информации Создание хорошо масштабируемых интеграционных охватывающих сервисы. Для транзакций, решений. растянутых на множество шагов, сложно Полная автономность отдельных сервисов (сервисы добиться независимо транзакция проектируются, версионируются и обеспечения в целостности рамках целостности, транзакций, особенно затрагивает если разные поддерживаются). приложения и длится долго (дни, месяцы). Независимая масштабируемость отдельных сервисов. • Сложно Резкий согласованности рост нагрузки на отдельный сервис не «тормозит» всю систему. В SOA-системе перегружается лишь отдельный сервис, и проблема решается увеличением лишь его мощности. 56 добиться семантической информации интегрируемых решениях. в Интеграция на уровне пользовательского интерфейса 57  Доступ к функциональности приложения осуществляется через пользовательский интерфейс путем моделирования операций ввода\чтения данных с экрана.  Промежуточное ПО должно собрать информацию, отображаемую на экране во время сеанса работы пользователя с системой-источником данных. Эмулятор терминала моделирует поведение пользователя , воспринимается приложением – источником данных как обычный терминал, но может управляться программно. Интеграция на уровне пользовательского интерфейса 58 № Компонента Функции 1. Презентационный Визуальное представление данных, слой приложения- Обработка источника введенных пользователем данных и преобразование их в команды, выполняемые на уровне бизнес-логики. 1. Эмулятор терминала Моделирует сеанс работы пользователя с презентационным слоем. Обеспечивает доступ к данным экрана через API. Обеспечивает передачу команд приложения презентационному слою. 1. Приложение Использует данные источника, Генерирует команды. приложения- Интеграция на уровне пользовательского интерфейса 59 Преимущества • • Недостатки Работает с монолитными • Сложность поддержки, связанная с тем, что пользовательские приложениями интерфейсы изменяются чаще, чем программные интерфейсы и схемы Практически исключает данных. риск нарушения • Ограниченный целостности данных приложения-источника (данные • Не требует данным (доступны только данные, Отсутствие доступа к метаданным (теряется информация о типах данных, ограничениях, связях, логических элементах). • приложения-источника). • к отображаемые в пользовательском интерфейсе). защищены бизнес-логикой доступ никаких • Невысокая скорость (может потребоваться сбор данных из нескольких пользовательских форм). Сложность реализации (интеграционное решение должно изменений в приложении- моделировать источнике. регулярную смену паролей в соответствии с политикой безопасности поведение системы-источника. Это промежуточного кода.) пользователя. требует Например, написания обеспечивать большого объема Топология интеграционных решений 60  Базовые шаблоны связывания приложений:  Точка-точка,  Брокер,  Шина сообщений.  Простейшим вариантом является соединений системы с необходимым сервисом по типу точкаточка. Точка-точка 61  Интеграция осуществляется или через специальный программный интерфейс (API) или путем чтения\записи данных непосредственно в базу данных приложения. Как правило, для связи каждой пары приложений разрабатывается отдельный программный модуль, требующий поддержки и обновления в случае изменений в связанных приложениях. Преимущества • Простота небольшом Недостатки реализации при • количестве интегрируемых приложений Высокая стоимость поддержки интеграционного решения. • Плохая масштабируемость (добавление новой связи «точка-точка» требует добавления нового программного модуля). • Сильная связь между приложениями. • Сложность управления интеграционным решением, состоящим из большого числа обособленных модулей взаимодействия. • Сложный алгоритм синхронизации данных. Брокер 62  Компонент, выступающий в качестве посредника и обеспечивающий связь между приложениями.  Основными функциями брокера являются:    Маршрутизация - определение местонахождения системы-приемника. Регистрация конечных точек – это механизм, который системы используют для обнаружения друг друга. Трансформация – процесс преобразования данных из формата приложения источника в формат приложения приемника. Шина сообщений 63  Все приложения подключаются через специальный логический компонент, называемый шиной сообщений.  При использовании шины сообщений приложение-источник и приложение приемник больше не взаимодействуют напрямую.  Приложение посылает сообщение в шину, которая доставляет сообщение всем приложениям-получателям через общую инфраструктуру. Приложение –получатель взаимодействует только с шиной сообщений. У каждого приложения остается единственная связь.  Предназначена для :     распределение сообщений между приложениями; конвертирование транспортных протоколов между приложениемисточником и приложением-приемником; конвертирование форматов сообщений между приложением-источником и приложением-приемником; управление бизнес-событиями различных источников. Шаблоны шины сообщений 64 Шина сообщений 65  Наиболее часто интеграционная шина используется для решения следующих задач:       Обмен сообщениями между приложениями; Синхронизация справочной информации между различными приложениями; Реализация сквозных бизнес процессов; Организация единой точки доступа к услугам (сервисам); Унификация взаимодействия с партнерами; Мониторинг бизнес активности. Способы получения сообщений из шины 66  Puch (толкать) – шина инициирует передачу сообщений ожидающему приложению. Подходит для приложений способных поддерживать постоянное соединение и прослушивать канал  Pull (тянуть) – приложение инициирует передачу сообщения, посылая запрос шине. Подходит для приложений, соединяющихся с шиной периодически. Шина сообщений 67 Преимущества • Недостатки Кроссплатформенность - обеспечение взаимодействия приложений, • работающих на различных аппаратных платформах и программных • Слабая связность интегрируемых приложений обеспечивает возможность переноса/замены одного из приложений без последствий для других приложений; • Масштабирование - возможность строить решения любого размера и нагруженности; • Гибкость и адаптивность - возможность реализовывать и изменять интеграционные сценарии по бизнес-запросу; • Использование открытых стандартов. • Уменьшение дублирования разработки приложений - использование функционала (сервисов) реализованного в одних приложениях для целей других приложений и информационных систем, вместо повторной реализации данного функционала. • Централизация механизмов реализации. • платформах; управления мониторинга, интеграционных процессов и контроля —использование администрирования, единых модификации Сложность Высокая стоимость. Интеграция данных предприятия ЛЕКЦИЯ 3 по дисциплине «ИНТЕГРАЦИЯ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ» Доцент кафедры «Бизнес-информатика» к.т.н., доц. Морозова О.А. Москва 2017 Содержание 2  Современные тенденции интеграции данных  Проблемы сбора, синхронизации и использования информации в масштабе предприятия  Проблема качества данных  Типы данных предприятия  Концепция MDM Эволюция запросов бизнеса к ИТ 3 Источник https://www.ibs.ru/datalab/works/data-governance/ Эволюция технологий 4  80-е – отдельные, не связанные приложения (application silos)  90-е – понятие бизнес-процесса, отдельные связи. Нет     стандартных протоколов и интефейсов. Взлет ERP 2000 – универсальные протоколы обмена данными. Интеграционные сервера. Интеграционная шина. Тренд – интеграция приложений. 2000- 2010 – механизмы интеграции данных (ETL, MDM, OLAP) 2000-2010 – решения для интеграции данных, а не систем (ХД, задача- аналитическая отчетность, расширение функционала, вытесняют интеграционные шины – задачи интеграции стали решаться непосредственно на уровне КХД). 2010 – появились доступные бизнесу технологии работы с неструктурированной информацией (видео, звук, тексты, логи и пр.). Новые требования к хранению, обработке и анализу данных. Современная ИТ-архитектура 5  Экза-хранилище – центральный компонент корпоративной ИТархитектуры  Приложения – пользователи сервисов экза-хранилища  «Датацентричная корпоративная ИТархитектура»  Новая парадигма ведения бизнеса – интеграция между собой внутренних и внешних информационных потоков, управление, предиктивные решения Data Governance 6  Data Governance - обеспечение организационного процесса управления корпоративными данными, управлением данными как активом организации. Задачи:  создание специальной организационной единицы  методическое обеспечение управления жизненным циклом данных  поддержание корпоративной модели данных Интеграция данных и ИТ-стратегия 7  В компании должен вырасти внутренний заказчик CIO и CDO (Сhief Data Officer) Задачи:  создать ИТ-архитектуру компании, которая позволит быстро развертывать новые сервисы поверх единого корпоративного хранилища  инфраструктура высокой готовности, высокой гибкости, с учетом всех новых платформ и необходимости адаптации к будущим изменениям  задача - сделать цифровые данные организации активом Проблемы сбора, синхронизации и использования релевантной информации в масштабах предприятия 8 Укрупнение предприятий, образование корпораций и холдингов, многофилиальных структур, территориально распределенных предприятий. Задачи: 1. Не потерять и максимально эффективно использовать накопленные данные. 2. Консолидировать отчетность и справочники. 3. Разработать бизнес-процессы, ориентированные на клиента. Проблемы по отраслям 9 Проблемы сбора, синхронизации и использования информации (на примере КО) 10 Решение о розничном проекте ИТ-риски При росте объемов оказываемых операций существенное снижение производительности некоторых ключевых операций АБС,  Снижение обслуживаемости АБС,  Повышение возможного ущерба от нештатных ситуаций в работе АБС,  Повышение функциональной нестабильности системы из-за более частого ее изменения и т.п.  Распределение потоков данных на уровне бэкофисных АБС Приобретение РС АБС Бизнес-проблемы:Проблема единого клиента, Проблема единого корр-счета,  Проблема единой кассы.  Проблемы сбора, синхронизации и использования информации (на примере КО) 11 Проблема – клиент банка учитывается в двух и более системах. Риски:   Возможное мошенничество при повторном использовании услуги по другим документам (при кредитовании). Санкции надзорных органов из-за некорректной отчетности («О форме реестра обязательств банка перед вкладчиками). Проблема – межбанковские платежи (входящие и исходящие) учитываются в нескольких системах. Следствие:     Отсутствует оперативная информация об остатках на корсчетах банка, Данные для исходящих рейсов находятся в нескольких системах, Входящие рейсы надо разделять на несколько систем. Затрудняется процесс построения обязательной отчетности перед ЦБ (формы 0409501, 0409603 и др.) Риски:   Потеря клиентской базы вследствие невозможности исполнения платежей клиентов. Потеря клиентской базы вследствие низкой скорости оказания услуг. Проблемы сбора, синхронизации и использования информации (на примере КО) 12 Проблема – кассовые операции учитываются в нескольких системах. : Следствие   Отсутствует оперативная информация размере денежной наличности в банке, Затрудняется процесс построения обязательной отчетности перед ЦБР (формы 0409601, 0409744, 0409202 и др.) Риски:   Санкции ЦБР вследствие несвоевременной сдачи или некорректной подготовки обязательных отчетных форм. Финансовые потери из-за неэффективного управления денежной наличностью. Качество данных 13 Качество данных - свойство данных удовлетворять предъявляемым к ним требованиям и затрагивает только те данные, которые участвуют в принятии какого-либо управленческого решения.  Плохое качество данных на этапах планирования и реализации является основной причиной провала 40% бизнес-инициатив.  Плохое качество данных повышает стоимость процессов с среднем на 20%  На 10% снижает эффективность ИТ  Ошибки в данных снижают производительность труда в среднем на 20%. https://www.gartner.com/doc/1819214/measuringbusiness-value-data-quality Стандарты качества данных 14 Стандарты качества данных 15 Редак Стандарт ция 1 ISO/TS 8000-1:2011 Data quality — Part 1: Overview ГОСТ Р 56214-2014 Качество данных. Часть 1. Обзор ISO 8000-2:2012 Data quality -- Part 2: Vocabulary 1 1 1 Дата публикации 2011-12 2014-11 2012-06 ГОСТ Р ИСО 8000-2-2014 Качество данных. Часть 2. Словарь 2014-11 ISO 8000-140:2016(en) Data quality — Part 140: Master data: Exchange 2016-10 of characteristic data: Completeness ISO 8000-100:2016(en) Data quality — Part 100: Master data: Exchange 2016-10 of characteristic data: Overview ISO 8000-130:2016(en) Data quality — Part 130: Master data: Exchange of characteristic data: Accuracy 2016-10 Свойства данных 16 ISO/IEC25012:2008  Внутренне присущее качество данных (Inherent data quality) –степень, в которой характеристики качества данных потенциально способны удовлетворять заявленным и предполагаемым требованиям при использовании данных в определенных условиях.  Системно зависимое качество данных (System dependent data quality) – степень, к которой качество данных достигается и сохраняется в компьютерной системе при использовании данных в определенных условиях. С этой точки зрения качество данных зависит от технологического домена, в котором используются данные и обеспечиваются возможностями компонентов компьютерных систем. Характеристики качества данных 17 Характеристика качества данных Внутренне присущие Системно зависимые Точность (Accuracy) x Полнота (Completeness) x Согласованность (Consistency) x Достоверность (Credibility) x Актуальность (Currentness) x Простота доступа (Accessibility) x x Соответствие (Compliance) x x Конфиденциальность(Confidentiality) x x Эффективность (Efficiency) x x Правильность (Precision) x x Контролируемость (Traceability) x Понятность (Understandability) x Доступность (Availability) x Переносимлость (Portability) x Восстанавливаемость (Recoverability) x Проблема качества данных 18 Управление качеством данных на предприятии (Enterprise Data Quality Management, EDQM). EDQM –часть процесса управления качеством на предприятии.  Уровни качества данных:     Технический – на качество данных влияют факторы, связанные с нарушением их структуры, целостности и полноты, некорректные форматы и представления данных (мешают корректно проводить консолидацию, загрузку в ХД, применять алгоритмы обработки). Аналитический – наличие факторов, мешающих корректному выполнению анализа (шумы, аномальные значения, дублирующиеся и противоречивые записи, пропуски, фиктивные значения и др.). Концептуальный уровень – проблемы, связанные с неверной стратегией сбора данных на предприятии (не содержат достаточно информации для анализа, неинформативные атрибуты). Классификация проблем качества данных 19 Выявление проблем в данных 20 Два взаимосвязанных метода анализа –профайлинг данных и Data mining. Профайлинг данных Профайлинг данных – грубый анализ отдельных атрибутов данных. Ориентирован на анализ технических проблем, которые относятся к наиболее типичным и хорошо формализуемым. Метод предварительной оценки качества данных. Автоматически проводятся исправление выявленных ошибок по заданным сценариям. Определяется информация о некотором поле источника данных и проверяется ее соответствие заданным ограничениям. Если параметры удовлетворяют ограничениям, то данные соответствуют определенному уровню качества. Выполняется на основе анализа метаданных, описывающих структуру данных. Анализируемая информация:  Тип атрибута (поля) – если тип атрибута поля не соответствует заданному, производтся соответствующее преобразование данных.  Длина значения – задается максимально допустимое количество символов.  Дискретные значения – проверяется частота появления дискретных значений, их уникальность.  Диапазон допустимых значений – задается интервал значений. Значения, выходящие за границы, меняются на значения, заданные по умолчанию.  Анализ строковых шаблонов – задаются шаблоны (почтовых индексов, номеров телефонов, номеров л/с). Если строка в ячейке соответствует шаблону (например, ХХХ-ХХ-ХХ), то ошибки нет. Иначе запускается обработка строки в соответствии с заданным сценарием. Трансформация данных 21 Комплекс методов и алгоритмов, направленных на оптимизацию представления и форматов данных с точки зрения решаемых задач и целей анализа. Цель представить информацию так, чтобы она могла использоваться наиболее эффективно. На этапе ETL-процесса трансформация производится с целью приведения данных в соответствие с моделью, которая используется в хранилище, а также обеспечения процесса консолидации данных и их загрузки в хранилище. Основные методы трансформации данных:         Квантование, Нормализация и кодирование данных, Сортировка, Слияние, Трансформация упорядоченных данных (скользящее окно, преобразование даты времени), Группировка и разгруппировка, Настройка набора данных (изменение имен и типов данных), Табличная подстановка значений. Трансформация данных. Квантование 22 Выполняется в два шага:  Диапазон числовых числовой величины значений разбивается на указанное количество интервалов определенным методом (равномерное и неравномерное квантование).  Замена каждого обрабатываемого значения на число, связанное с интервалом, к которому оно относится, либо на метку интервала. В качестве результатов квантования могут быть использованы:  Нижняя граница интервала квантования (вместо значения, попавшего в интервал устанавливается нижняя граница интервала),  Верхняя граница интервала квантования,  Середина интервала,  Метка интервала (можно задать произвольное значение, обозначающее интервал, например наименование категории, к которой будет относиться объект). Позволяет развить признак по категориям. Цели квантования:  Изменение вида данных (переход от непрерывных к дискретным).  Сокращение размерности данных (сокращение числа значений признака). Пример распределение заемщиков по категориям. Трансформация данных. Нормирование и кодирование данных 23  Кодирование – процесс приведения переменных к числовому представлению.  Нормирование – приведение входных и выходных величин к единому масштабу. Методы нормирования:     Десятичное масштабирование (перемещение десятичной точки на количество цифр, которое определяется из максимального значения признака), Минимаксная нормализация, Нормализация с помощью стандартного отклонения (применяется, если данные распределены неравномерно, есть выбросы), Нормализация с помощью поэлементных преобразований (экспоненциальное, логарифмическое, степенное преобразование) . Методы кодирования:   Преобразование категориальных данных в числовые коды. Двоичное кодирование (кодирование с помощью двоичных чисел –маски). Обогащение данных 24 Обогащение данных – процесс насыщения данных новой информацией, которая позволяет сделать их более ценными для решения некоторой аналитической задачи. Два основных метода:   Внешнее обогащение – выполняется за счет привлечения дополнительной информации из внешних источников (курсы валют, котировки, статистические данные и др.). Внутреннее обогащение – повышение информативности данных за счет их внутренней организации. Получение и включение в набор данных информации, которая отсутствует в явном виде, но может быть получена с помощью манипуляций с имеющимися данными. Новая информация встраивается в виде новых полей или новых таблиц в ХД. Типы данных 25  Оперативные (транзакционные) данные – текущие данные, используются как правило в одном бизнес-процессе. Данные, отображающие результат выполнения транзакции и относящийся непосредственно к бизнес операции. «Transactional Data», «Application Specific Data», «Operational Data».  Нормативно-справочные данные (НСИ) – условно-постоянные данные, используются в документах, относящихся к разным бизнеспроцессам. «Reference Data», «Lookup Data», «Dictionaries», НСИ.  Мастер данные – сущности, взаимосвязи и атрибуты, которые важны для предприятия и лежат в основе ключевых бизнес-процессов и систем автоматизации.  Метаданные – данные о данных. Типы данных. Идентификация Критерий Ссылочные данные (НСИ) Типичные Справочники, нормативы, данные. сокращения, кодификаторы, акронимы, стандарты, словари, «бизнес-правила» в виде диапазонов, пороговых значений, констант, последовательностей и пр. Могут использоваться для нормализации в БД. Часто являются связующим звеном между мастер-данными и транзакционными. Выражают «факт». Самодостаточны. 26 Мастер Данные Транзакционные Данные Основные объекты организации, прошедшие процедуры «очистки» и согласования. Выражают «базовые объекты». Данные, отражающие транзакцию в системе. Содержат собственно результат транзакции. Часто представлены комбинацией Мастер Данных и Ссылочных данных (НСИ) и дополнительных специфичных для данной транзакции атрибутов. Выражают «действие-результат». Типы данных. Идентификация 27 Критерий Ссылочные данные (НСИ) Мастер Данные Транзакционные Данные Скорость изменения модели данных. Модель данных практически стабильна на протяжении использования. Модель данных меняется редко и в основном как ответ на адаптацию к новым бизнес требованиям и расширению моделей в транзакционных системах в части, относящейся к основным данным предприятия. Модель данных меняется часто в зависимости от новых бизнестребований к системе. Скорость изменения данных. Очень низкая. Практически не изменяются. Низкая, данные меняются в момент изменения мастер данных в одной из IT систем (или МДМ системе) и формирования «золотой записи». Высокая. Меняются в каждой бизнес транзакции. Типы данных. Идентификация 28 Критерий Ссылочные данные (НСИ) Мастер Данные Критичность к качеству данных. Очень высокие требования к качеству данных. Недопустима путаница, разночтения и дублирование данных. Высокие Высокие требования. требования к Качество данных качеству. определяется транзакционной системой, в которой, как правило, заданы механизмы "компенсации" ошибок. Количество данных. Небольшое, часто отражает реальные "факты", количество которых заведомо конечно. Изначально достаточно большое. Конечное множество.. Транзакционные Данные Количество данных не ограничено. Типы данных. Идентификация 29 Критерий Ссылочные данные (НСИ) Мастер Данные Транзакционные Данные Время жизни. В случае внешних для огранизации данных - существовали по факту до начала создания/эксплуатации IT систем организации. В случае внутренних данных - существуют все время существования бизнеса предприятия. Появляются и поддерживаются на протяжении всего времени существования бизнеса предприятия. Чаще всего время жизни определяется временем жизни соответствующей транзакционной системы. Типы данных. Идентификация 30 Критерий Ссылочные данные (НСИ) Взаимосвязь с Не включают в себя другими типами и не ссылаются ни данных. на какие другие типы данных. Мастер Данные Транзакционные Данные Включают в себя или ссылаются на Ссылочные данные (НСИ). Включают в себя или ссылаются на любые другие типы данных. Типы данных. Идентификация 31 Критерий Ссылочные данные (НСИ) Места появления данных внутри Предприятия . - МДМ система. - Транзакционные - Транзакционные системы. системы. - МДМ система. - Часто "прошиваются в код" исполняемых модулей IT систем. - Глоссарий Предприятия. Особенности Объекты с небольшим модели количеством атрибутов. Неглубокий уровень вложенности в классификаторах. Не развитые механизмы поддержки историчности Мастер Данные Объекты с большим количеством атрибутов и сложными взаимосвязями. Развитые механизмы для хранения истории изменений. Транзакционные Данные - Транзакционные системы Определяется спецификой транзакционной системы. В общем случае модель содержит много объектов с различным количеством атрибутов. Проблемы управления НСИ • • • • • • • • 32 неполнота, противоречивость, недостоверность или некорректность в наименованиях, описаниях и других атрибутах объектов; наличие устаревшей информации в справочниках; неунифицированность наименований объектов; наличие дублированных объектов (повторный ввод данных); отсутствие необходимых связей между элементами НСИ; ошибки в структуризации объектов; отсутствие классификаторов для больших справочников НСИ; недостаточный учет в существующих массивах НСИ информационных потребностей структурных подразделений и бизнес-процессов компании. Проблемы ведения НСИ  33 В ИТ-системах нормативно-справочная информация определяется как совокупность условно-постоянных данных, на которых основываются процессы формирования учетных документов в компании (учреждении). Виды НСИ и способы ведения Кодификатор создается разработчиками конкретной базы данных для внутренних нужд. Обычно не используются алгоритмы расчета контрольной суммы, ни правила кодирования. Справочник ведется сторонней организацией. Нумерация кодов не подчиняется каким-либо правилам. Классификатор ведется централизованно внешней организацией и содержит правила формирования кода. Может определять правила использования кода и содержать контрольное число. Идентификатор (ИНН, ISBN) ведется децентрализованно уполномоченными организациями. В отличие от случая классификатора, коды идентификатора обязательно подчиняются правилам расчета контрольного числа. Пополняется индивидуальными кодами в процессе эксплуатации системы. Норматив может представлять собой просто некоторое числовое значение (например, ставка налогообложения), который получен из неструктурированного документа (приказа, закона, акта). Словари содержат сокращения, термины и другие строковые значения, которые необходимы на этапе генерации отчетов и форм. Наличие таких словарей в системе обеспечивает единую 34 терминологию во всех входных и выходных документах. Управление мастер данными 35  Управление мастер данными (MDM) – это набор процессов и технологий, направленных на создание и поддержание достоверной, точной, безопасной среды данных, формирующих «единую версию правды» мастер-данных и их взаимосвязей.  Управление мастер данными (MDM) – это процесс, в котором коммерческая и ИТ-составляющая соединены вместе в целях обеспечения стандартизации, точности, управляемости и распределения ответственности за информационные активы предприятия (определение Gartner). Классификация MDM 36 По домену данных (предметной области):  Домен клиентов – Customer Data Integration (CDI)  Продуктовый домен – Product Information Management (PIM)  Другой (основной домен данных, которым управляет MDM-система) В зависимости от домена могут сильно отличаться требования к согласованности, точности, безопасности Классификация MDM 37 По шаблону использования:  Аналитическая MDM –поддерживает бизнес-процессы и приложения, использующие мастер-данные для анализа эффективности бизнеса (отчеты, аналитические функции). Напрямую взаимодействует с BI. Не меняет данных в транзакционных системах, считывает данные из источника, очищает и обогащает их, может формировать сложные измерения данных. Может быть спроектирована как источник данных для ХД.  Операционная MDM – собирает, изменяет и использует мастер данные в процессе выполнения бизнес-транзакций. Используется для поддержки семантической согласованности мастер-данных о транзакционных системах. Улучшает качество данных в транзакционных системах.  Коллективная MDM – шаблон, в котором пользователи создают объекты мастер-данных и поддержании их актуальности. Классификация MDM 38     По архитектуре: Хаб внешних ссылок Реестровый хаб Реконсиляционный хаб Транзакционный хаб Хаб внешних ссылок 39 Это БД, которая содержит реестр идентификаторов и ссылок на приложения, владеющие мастер-данными.  Мастер-данные хранятся и обрабатываются приложениями.  Минимальны изменения в приложениях.  MDM hub должен содержать маппинги ссылок на все записи с общим ключом. Каждый запрос к данным – это распределенный запрос к нескольким системам.  Не содержит никаких атрибутов для сопоставления и разрешения сущностей. При сопоставлении сущностей выполняется распределенный запрос к нескольким системам.  Необходимо поддерживать точные ссылки на мастер-данные, требуются надежные связи с системами источниками (механизм обмена сообщениями) Неэффективная архитектура. Большинство разработчиков прекратила поддержку решений. Реестровый хаб 40 Это реестр уникальных идентификаторов мастер сущностей (строится по идентифицирующим атрибутам)  Хаб сопоставляет и объединяет записи, содержащие одинаковые       идентифицирующие параметры Выступает в качестве владельца уникальных идентификаторов мастерсущностей, разрешает конфликты в данных по определенным правилам Создает и поддерживает связи с источниками данных. Возвращает в приложение-приемник сформированное целостное представление сущности (извлекает из хаба или собирает в реальном времени). Для получения лучшего представления мастер-сущности все системыисточники должны быть доступны Хаб не используется для ввода данных и не владеет мастер-данными, только решает задачу выбора лучшего значения. Хаб отображает изменения, возникающие в источниках, отображает эталонное представление мастерзаписи Значения атрибутов создаются и поддерживаются в системах-источниках Корректное значения должны поддерживаться в одном из приложенийисточников Мастер данные интегрируются виртуально Реконсиляционный хаб 41 Система записей для некоторых атрибутов, обеспечивает активную синхронизацию данных между MDM-системой и имеющимися системами  Хаб является владельцем основных идентифицирующих атрибутов, эти атрибуты создаются и изменяются в хабе  Хаб передает изменения идентифицирующих атрибутов в системы  Сложная синхронизация (данные непрерывно синхнонизируются между участниками процессов)  Иногда необходимо изменять или перепроектировать приложения-источники мастер-данных Пример: хаб создает и поддерживает уникальные идентификаторы клиентов и ссылки на имеющиеся системы и ХД, откуда извлекаются данные о клиентах и где они продолжают храниться. Мастер данные интегрируются физически Транзакционный хаб 42 Самый сложный вариант архитектуры. Хаб –основной источник мастер-данных домена.  Хаб – поддерживает все атрибуты сущности. Ваделец данных о мастер-сущности, является источником всех изменений любого атрибута.  Транзакционная среда, обеспечивает целостность данных  Сильно влияет на работающие приложения. Все приложения, которые меняют информацию о сущностях должны напрямую работать с хабом (могут измениться бизнес-процессы, регламенты, интерфейсы). Мастер данные интегрируются физически Референтная архитектура MDM 43