Интеграция ис с общей бизнес стратегией компании

5. Интеграция информационных систем предприятия

5.1. Взаимосвязь информационных подсистем предприятия

Каким образом связаны информационные системы внутри предприятия? Обычный путь для российской компании средних размеров — начинать внедрение информационных технологий с автоматизации работы бухгалтерии, отдела кадров и документооборота. Данные этих систем наиболее формализованы, процессы легко автоматизируются. Широко распространенные пакеты «1C: Бухгалтерия», «Босс: Кадровик», «LanDocs», «LanStaff», «Salary» и др. позволяют наращивать себя любыми приложениями и, таким образом, интегрировать их в общую информационную систему предприятия. Рис. 5.1 показывает, каким образом модули информационной системы компании связаны друг с другом. Модуль TPS обслуживает основные производственные и вспомогательные процессы, и обычно это главный источник для других информационных модулей. ESS — главный получатель данных и внутренних систем и внешней среды.

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

Связи между DSS и совокупностью TPS, KWS, MIS намеренно показаны неопределенными. Иногда DSS тесно связана с другими подсистемами. Но это только в том случае, если предприятие отличается высокой степенью автоматизации всех процессов. Обычно подсистема DSS изолированы от основных производственных информационных систем и использует их данные и информационные потоки для работы своих аналитических систем.

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

5.2. Сервис-ориентированная архитектура ИС

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

В настоящее время при формировании информационной инфраструктуры предприятия, при проектировании и реализации КИС всё чаще применяется сервис-ориентированная архитектура (Service-Oriented Architecture — SOA). Это такая архитектура ИС, в которой система строится из набора гетерогенных слабосвязанных компонентов (сервисов). SOA понимается как парадигма организации и использования распределенного множества функций, которые могут контролироваться различными владельцами. Базовыми понятиями в такой архитектуре являются «информационная услуга» и «композитное приложение».

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

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

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

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

Использование такого подхода при построении архитектуры сложных интегрированных информационных систем позволяет:

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

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

Обязательным условием построения и внедрения архитектуры системы на основе SOA является использование единой инфраструктуры описания сервисов (репозитория сервисов), разрешенных протоколов доступа и обмена сообщениями, форматов сообщений.

Упомянутая инфраструктура образует так называемую интеграционную шину (Enterprise Service Bus — ESB), являющуюся одним из центральных компонентов системы. Она устанавливает единые правила публикации сервисов, управления и информационного взаимодействия между приложениями различных систем, входящих в состав интегрированной системы. Это упрощает управление приложениями и их поддержку, а также снижает риск фрагментации приложений и процессов.

Основные компоненты архитектуры информационной системы, построенной на основе концепции SOA и ESB, представлены на рис. 5.2.

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

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

По данным Gartner Group («Predicts 2007: SOA Advances», 17 ноября 2006): «К 2008 году SOA станет господствующей архитектурой построения ИТ-систем, что приведет к окончанию 40-летней эры господства архитектуры монолитных приложений». Отметим, что этот прогноз в большой степени оправдался.

Изменение и совершенствование бизнес-процессов в компаниях занимает годы. По усредненным данным Gartner Group: 80 % ИТ-бюджета — это расходы на сопровождение систем, из них 35 % — затраты на интеграцию приложений, 60 % стоимости внедрения корпоративной ИС составляют расходы на интеграцию, 50 % ИТ-бюджета потрачено на обеспечение интерфейсов систем. Использование SOA архитектуры позволяет эффективно организовать оперативную адаптацию ИТ-систем под требования бизнеса, что дает стратегическое преимущество компании, заключающееся в:

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

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

Основные бизнес-цели внедрения SOA-решений состоят в ликвидации:

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

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

• обеспечивать преемственность инвестиций в IT, сохранение существующих информационных систем и их совместное эффективное использование для повышения ROI от IT-вложений;
• обеспечивать реализацию различных типов интеграции:
  • пользовательская интеграция (User Integration) — обеспечение взаимодействия информационной системы с конкретным персонифицированным пользователем;
  • интеграция приложений (Application Connectivity) — обеспечение взаимодействия приложений;
  • интеграция процессов (Process Integration) — интеграция процессов в соответствии с бизнес-логикой деятельности предприятия;
  • информационная интеграция (Information Integration) — интеграция с целью обеспечения доступности информации и данных;
  • интеграция новых приложений (Build to Integrate) — интеграция новых приложений и сервисов в существующие информационные системы.
• обеспечивать поэтапность внедрения вновь созданных и миграции существующих информационных систем;
• иметь стандартизованную технологическую обеспеченность реализации и инструментарий разработки, совокупно предоставляющие наилучшие возможности повторного использования приложений, внедрения новых и миграции существующих информационных систем;
• позволять реализацию различных моделей построения информационных систем, в особенности таких как портальные решения, grid-системы и on-demand-системы.

Сегодняшний уровень развития SOA позволяет утверждать, что все указанные требования в той или иной мере выполняются. Рост рынка продуктов для SOA-решений — 100 % в год. В 2007 году SOA была использована как основа создания 50 % новых, критичных для бизнеса приложений и бизнес-процессов; к 2012 году этот показатель вырос до 85 %. Более 80 % приложений, введенных в промышленное использование в 2010 году, будут частично или полностью перепроектированы к 2014 году, чтобы быть использованы в построении композитных приложений в SOA-архитектуре.

К 2014 более 80 % всех программных инфраструктурных продуктов будут включать корпоративную шину сервисов или требовать ее использования. Среди исполнительных директоров компаний 58 % считают, что в период до 2015года в числе главных стратегических преимуществ компаний новые модели ведения бизнеса имеют бoльшее значение, чем выпуск новых продуктов и услуг. По данным Forrester («The State of SOA in Financial Services», январь 2014 года) «Большинство финансовых компаний будут использовать SOA к концу 2014 г. В настоящее время более 60 % европейских финансовых компаний или уже используют SOA или на последней стадии внедрения».

5.3. Варианты интеграционных решений

Многообразие применяемых технологий и систем, разнообразие форматов данных, циркулирующих в информационных потоках, обилие аналитических и отчётных форм сделали чрезвычайно актуальной задачу интеграции указанных выше технологических и информационных объектов и сущностей, а также физические и виртуальные пространства их взаимодействия в единую информационно-управленческую среду (рис. 5.3) [Н.И. Куцевич.,http://www.rtsoft.ru].

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

Подход к разработке и внедрению КИС, основанный на интеграции приложений, позволяет:

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

Интеграция на уровне данных

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

Для их интеграции в настоящее время обычно используют стандартные интерфейсы и протоколы, например, SQL и JDBC/ODBC, применяют различные инструменты реляционных баз данных (Relational Database — RD), сквозных репозиториев — баз данных с «надстройкой», содержащей информацию об артефактах и объектах проектирования, надмножество словарей метаданных (Transparent Repository — TR) и современных хранилищ и фабрик данных (Data Warehouse, Data Factory — DW, DF).

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

Интеграция на уровне физических, программных и
пользовательских интерфейсов

Этот вид интеграции начинался как один из видов «лоскутной интеграции», когда предпринимались попытки объединить разрозненные программные приложения, написанные в разное время разными разработчиками, в подобие единого целого. Приложения объединялись по принципу «каждый с каждым», что, в конечном счёте, усложняло их взаимодействие и создавало массу проблем. Кроме того, всё сложнее становилось использовать унаследованные (Legacy Software) и встроенные (Embedded System) системы.

Такой подход хорош для небольшого количества приложений. При большом их числе он практически не работает и не позволяет строить качественно новые запросы к агрегированным данным, т.е. существенного выигрыша от объединения данных нет. В настоящее время проблема интеграции на уровне интерфейсов решается на базе использования информационных подсистем, реализованных стандартными программными приложениями с открытыми интерфейсами (Open Application Programming Interface).

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

В настоящее время всё чаще применяется следующий алгоритм: отделяют слой обработки данных от привязанных к ним форм визуализации и реализуют прикладную бизнес-логику на одном из языков третьего поколения (3GL), оформив программный доступ к прикладным функциям в виде хорошо документированного программного интерфейса (рис. 5.5).

Интеграция на функционально-прикладном и
организационном уровнях

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

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

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

Интеграция на уровне приложений (Enterprise Application Integration — EAI,) подразумевает совместное использование исполняемого кода, а не только внутренних данных интегрируемых приложений. Программы разбиваются на компоненты, которые интегрируются с помощью стандартизованных программных интерфейсов и специального связующего ПО.

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

В связи с этим технология интеграции в настоящее время рассматривает не просто интеграцию приложений, но их интеграцию на базе интеграции бизнес-процессов – в этом случае следует говорить об интеграции на уровне всего предприятия (Enterprise Integration Metodology — EIM). Схема такой объединенной методологии показана на рисунке 5.6.

Методология EIM реализуется современными технологиями и инструментами, среди которых можно, например, указать рассмотренную выше технологию интеграции на базе сервис-ориентированных архитектур (SOA). Архитектура ИС в таком случае строится из набора гетерогенных слабосвязанных компонентов (сервисов) и понимается как парадигма организации и использования распределенного множества функций, которые могут контролироваться различными владельцами. Базовыми понятиями в такой архитектуре являются «информационная услуга» и «композитное приложение».

Интеграция при помощи Web-сервисов

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

Например, используя стандартный протокол доступа к объектам SOAP (Simple Object Access Protocol), браузер пользователя может сравнить данные на нескольких сайтах и представить клиенту сравнительный отчет. Другой пример — сотрудники территориально распределенного предприятия могут одновременно использовать корпоративные приложения, доступ к которым осуществляется через соответствующие Web-сервисы (портальное решение).

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

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

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

Системные и бизнес-аналитики довольно часто участвуют в проектах интеграции информационных систем. Сегодня рассмотрим, с чего начать предпроектное исследование, чтобы успешно разработать требования к интеграции и оформить их в виде технического задания (ТЗ) по шаблонам российских ГОСТ’ов (34.602-89 и 19.201-78) или международных стандартов спецификации. Также разберем, чем пакетный парсинг отличается от потоковой передачи событий и каковы сложности интеграции нескольких информационных систем с разными моделями данных.

Что такое интеграция информационных систем: краткий ликбез для бизнес-аналитика

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

Зачем?

Поскольку любое исследование в бизнес-анализе начинается с определения потребности, неудивительно, что «Зачем?» – это первый вопрос при интеграции ИС.  Зная ответ, аналитик сможет определить полезность и нужность, т.е. ценность интеграции для бизнеса: решает ли она реальную проблему и действительно ли эту проблему стоит решать. Например, сотрудники компании тратят 2 часа рабочего времени на внесение данных из одной информационной системы в другую. Зная количество этих сотрудников и их почасовую ставку, нетрудно рассчитать экономию от автоматической передачи данных между разными системами. Это и будет ценность интеграции в денежном выражении. Сопоставив потенциальную выгоду интеграции с затратами на ее реализацию, можно сделать выводы о периоде окупаемости интеграционного решения и его целесообразности. Подробнее о бизнес-проблемах, их причинах и следствиях мы говорили в прошлой статье.

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

Сколько?

Хотя главным вопросом для бизнеса являются деньги и то, что с ними связано, здесь речь идет не о стоимости интеграционного решения, а о том, какое количество ИС необходимо связать между собой. Если нужен обмен данными между всего 2-мя «коробочными решениями», а бизнес не планирует строить полноценную инфраструктуру данных, добавляя десятки специфических ИС для поддержки различных процессов и направлений деятельности, то границы проектируемого интеграционного ПО могут располагаться внутри 2-х связываемых систем. Когда речь идет о создании корпоративной дата-магистрали, к которой подключено много ИС, при разработке ТЗ аналитику нужно тщательно проработать требования к внешним интерфейсам, которые будут обеспечивать многосторонний обмен данными.

На основании этих требований и особенностей самих связываемых систем ИТ-архитектор принимает решение о модели интеграции. Например, это может быть общая шина предприятия (ESB, Enterprise Service Bus) с очередью сообщений, набором коннекторов к источникам и приемникам данных, а также объединяющей программной платформы. Или реализация CDC-подхода, когда с помощью триггеров отслеживаются и обрабатываются изменения в базах данных прикладных систем (Change Data Capture), сливаясь в единое корпоративное хранилище (DWH, Data WareHouse). Или же обмен данными по запросу через удаленный вызов процедур из одной системы и обращение к конечной точке другой методами RESTful-API. Подробнее о способах интеграции ИС с технической точки зрения мы поговорим в следующий раз. А пока отметим, что при разработке ТЗ или спецификации требований информация о количестве связываемых ИС и их архитектурных особенностях будет отражена в разделе «Ограничения дизайна и реализации».

Какие данные?

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

Например, в одной системе адрес хранится в одном поле таблицы строкового типа, а в другой – разбит на несколько отдельных полей с разными типами данных: индекс, область, город, улица, номер дома, корпус, квартира. В этом случае интеграционное решение будет выполнять синтаксический анализ (парсинг) исходных данных, чтобы выделить разные значения из единой строки и записать их в различные поля модели данных системы-приемника. Аналогичный парсинг будет выполняться и для сложных типов данных в случае интеграции нескольких систем, например, при разборе сообщений, хранящихся в очереди корпоративной ESB-шины. Описать данные, которыми будут обмениваться интегрируемые системы, а также сопоставить компоненты одной модели данных и другой поможет техника под названием «Словарь данных», которую мы недавно разбирали здесь. В дополнение к этому будет полезно показать источники и приемники данных с процессами их преобразования. Сделать это можно с помощью диаграмм потоков данных (DFD, Data Flow Diagram), которые мы разбирали в этой статье.

Как часто или насколько быстро выполняется обмен?

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

Кто или что инициирует передачу данных?

Наконец, при разработке требований к интеграционному решению аналитик должен определить сценарии интеграции с точки зрения ролей в процессе обмена данными: кто из пользователей или какая из систем инициирует передачу данных. Это можно оформить в виде текстовых сценариев Use Case в разделе описания функциональных требований. Для наглядности такие сценарии можно проиллюстрировать диаграммами описания бизнес-процессов в BPMN или UML-activity, однако на практике именно для проектов интеграции такие схемы не всегда действительно нужны, в отличие от матрицы ролей и разрешений.

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

А детально познакомиться с основами архитектуры и интеграции информационных систем вам помогут курсы Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

• Основы архитектуры и интеграции информационных систем
• Разработка ТЗ на информационную систему по ГОСТ и SRS

Лохин Ю.Н.
Выпускник группы МВА CIO-28
Школы IT-менеджмента
РАНХиГС при Президенте РФ

Связь ИТ стратегии и стратегии бизнеса. Место ИТ стратегии в управлении бизнесом

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

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

Поэтому основой для формирования любой ИТ стратегии может и должна служить стратегия развития бизнеса.

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

Что такое ИТ стратегия. Ключевые факторы, влияющие на разработку стратегии. Состав документа

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

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

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

• Признание информационных технологий в качестве неотъемлемой части деятельности предприятия;
• Распределение ответственности по реализации ИТ стреатегии между бизнесом и ИТ;
• Цели стратегии должны базироваться на потребностях предприятия;
• Должно поддерживаться тесное взаимодействие с бизнес-заказчиками;
• Необходима концентрация на приоритетных целях и стратегических инициативах, а не на удовлетворении сиюминутных «одноразовых» потребностей;
• Необходимо обеспечить доступность и достаточность ресурсов. При этом объем данных ресурсов не должен превышать размер ожидаемого эффекта;
• ИТ-менеджменту необходимо поддерживать неформальные отношения с исполнительным менеджментом;
• Необходимо создание системы стратегического управления реализацией ИТ стратегии.

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

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

Документ формируется руководителем ИТ подразделения и согласовывается с руководителями бизнес-подразделений.

Подход к формированию ИТ стратегии

Рассмотрев основные принципы и подходы к формированию ИТ стратегии, факторы на нее влияющие и целесообразность формирования этого документа вообще, можно перейти к детальному описанию процесса создания ИТ стратегии.
Иллюстрироваться для большей наглядности процесс формирование ИТ стратегии будет на примере ЗАО «ЕВРОЦЕМЕНТ груп» — крупного международного Холдинга, по производству стройматериалов.
Первоочередной задачей при формировании ИТ стратегии является выяснение бизнес-стратегии, целей, потребностей и требований бизнеса и его проблем с точки зрения ИТ.
Естественно, самым простым и очевидным способом получения указанной информации было бы прочтение некоего документа, описывающего стратегию развития Холдинга на ближайшие 3-5 лет, но к сожалению зачастую подобные документы отсутствуют или представляют собой набор лозунгов мало связаных с реальностью.
Единственным доступным вариантом в подобной ситуации остается интервьюирование руководителей разного уровня, обсуждение с ними их потребностей, видения развития и т.п.
Именно такой подход был единственно возможным для формирования ИТ стратегии в ЗАО «ЕВРОЦЕМЕНТ груп», так как стратегия развития бизнеса была недоступна.
Для реализации данного подхода было сделано следующее:

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

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

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

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

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

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

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

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

Определение подходов к реализации ИТ стратегии

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

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

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

В результате был сформирован общий план-график реализации ИТ стратегии.

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

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

Управление реализацие ИТ стратегии

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

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

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

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

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

Заключение

Итак, стоит ли ИТ стратегия того, чтобы ее формировать? Ответ однозначный – стоит. И это нужно, в первую очередь, ИТ менеджеру. Именно благодаря сформированной, согласованной с бизнесом и успешно реализуемой ИТ стратегии в ЗАО «ЕВРОЦЕМЕНТ груп» удалось: бизнесу – взглянуть на себя со стороны и изменить подходы к своей работе, начать за счет реализации ИТ проектов работы по оптимизации бизнес-процессов. ИТ подразделению – поднять значение информационных технологий в целом и ИТ подразделения в частности, сделать бизнес своим союзником и заинтересованным лицом в развитии ИТ, вывести на новый уровень понимание бизнес-процессов и проектный подход и т.п. Ну и как менее значимые для бизнеса в целом, но более важные результаты для ИТ подразделения: сформировать и утвердить бюджет, необходимый для развития ИТ в Холдинге, увеличить численность и ФОТ подразделения до среднерыночного уровня.

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

Аннотация: Достоинства и недостатки походов к интеграции разных типов ИС, достоинства и недостатки

Ключевые слова: Информационная система; ESB; ETL; передача данных

MODERN APPROACHES TO THE INTEGRATION OF CORPORATE INFORMATION SYSTEMS

Annotation: Advantages and disadvantages of campaigns to integration of different types of IP, advantages and disadvantages.

Keywords: Information system; ESB; ETL; data transmission

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

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

Можно выделить несколько аспектов, которые обуславливают актуальность выбранной проблемы интеграции ИС.

Во-первых, цифровизация и автоматизация процессов компании приводит к значительному росту объема хранимых данных. Так, согласно исследованию IDC [1] увеличится более чем в 10 раз по сравнению с объемом данных в 2016 году и составит более 153 зеттабайт (ЗБ, 1 ЗБ — триллион гигабайт). Для эффективного использования распределенных данных необходимо решить проблемы сбора, синхронизации и использования релевантных данных в масштабах всей компании. Прежде всего, речь идет об управлении данными и обеспечении надлежавшего качества этих данных.

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

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

Эволюция подходов к интеграции информационных систем

Сама концепция интеграция информационных систем имеет долгую историю. Необходимость интегрирования информационных систем появилась сразу после того, как на предприятие внедрялось более одной ИС. По мере развития ИС менялись и подходы к их интеграции. Так в 70 — 80-е годы прошлого века корпоративные ИС выполняли довольно простые функции, которые заключались в автоматизации отдельных простых процессов. Постепенное усложнение ИС и увеличения выполняемых функций привело к появлению концепции модульных информационных систем. В начале 1990-х годов золотым стандартом комплексной автоматизации стало применение универсальной информационной системы, которая охватывала бы все сферы деятельности компании. Система такого класса должна быть основана на единой программно-аппаратной платформе и единой базе данных, а ее модули (или функциональные подсистемы) должны использовать единый технологический процесс обработки информации.

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

Примерам таких систем являются решения класса ERP (Enterprise Resource Planning) и CRM (Customer Relationship Management). Например, к базовым модулям CRM можно отнести автоматизацию службы поддержки клиентов, автоматизацию деятельности продавцов, автоматизацию маркетинга. Данные системы и сейчас используются повсеместно. Однако уникальные особенности каждого бизнеса не всегда позволяют перенести все процессы на тиражируемые решения универсальных систем.

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

Рисунок 1 — Схема неупорядоченной ИТ-инфраструктуры предприятия

Подходы к развитию ИТ-инфраструктуры предприятия

Принято выделять два основных подхода к развитию ИТ-инфраструктуры предприятия.

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

Второй подход — это мультивендорная стратегия развития ИТ-инфраструктуры. Данный подход строится на принципе «best-of-bread» (лучший в своем классе) и требует больших затрат для интеграции инородных систем в существующую ИТ инфраструктуру.

В данном подходе интеграция между системами строится на основе трехуровневой модели (см. Рисунок 2). В такой модели каждое бизнес-положение состоит из трех слоев(уровней):

— Уровень данных — это объекты базы данных;

— Бизнес уровень — это уровень бизнес логики (обработка данных, поддержка логики бизнес-процессов)

— Уровень пользовательского интерфейса — решает задачи вводы и вывода данных.

Рисунок 2 — Трехуровневая архитектура системы класса CRM Oracle Siebel

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

Подходы к интеграции систем

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

Современные системы класса middle ware — это сложное программное обеспечение, способное обрабатывать сообщения на базе универсальных форматов и обеспечивать многоканальную передачу сообщений между всеми бизнес-приложениями (см. Рисунок 3). Основными компонентами таких систем являются: Сервисная шина (основанная на архитектуре ESB — Enterprise Service Bus, выполняет функции переформатирования данных, маршрутизации сообщений, управления транзакциями, мониторинга и контроля взаимодействия приложений), набор адаптеров, которые позволяют различным приложениям подключаться к шине.

Рисунок 3 Архитектура решения класса middleware компании «Галактика»

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

Для обмена файлами большого объема между системами можно использовать интеграцию посредством ETL (Extract, Transform, Load — комплекс методов, с помощью которых реализуется перенос исходных данных из одного источника (ИС, хранилища данных) в другие источники) решений. Системы класса ETL подходят для интеграции систем в части обмена данными при условии, что нет необходимости построения интеграции в режиме реального времени. Например, ETL решения часто используются для интеграции банковских систем при передачи документов из одной системы в другую
(см. Рисунок 4). Хоть ETL и не позволяет передавать данные в режиме реального времени, для многих процессов обмена документов задержка в
15-20 минут не является критической, а стоимость такой интеграции относительно использования ESB меньше в несколько раз. Также плюсом построения интеграции с помощью средств ETL является простота настройки и изменений. При изменение формата данных, полей таблиц и т.д. необходимо выполнить аналогичные изменения в таблицах ETL, не изменяя программный код (см. Рисунок 5).

Рисунок 4 пример интеграции систем Siebel-MDM-АБС с помощью ETL решения Informatica PC

Рисунок 5 Пример настройки таблиц интеграции в Informatica PC

Выводы

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

Список литературы

1. CORBA [Электронный ресурс]. — Режим доступа: https://www.seagate.com/www-content/our-story/trends/files/Seagate-WP-DataAge2025-March-2017.pdf (дата обращения 10.06.2018)
2. Integration Patterns Overview [Электронный ресурс]. — Режим доступа: http://www.enterpriseintegrationpatterns.com/eaipatterns.html (дата обращения 11.06.2018)