Одной из основных задач для Enterprise архитекторов является проектирование и проведение работ по интеграции различных ИТ систем. Так типичной историей является наличие у заказчика каких-то решений, либо не взаимосвязанных, либо частично связанных между собой и архитектору необходимо встроить свое решение, интегрировав его с теми решениями, которые уже есть у заказчика.
Далее мы рассмотрим несколько подходов к интеграции, и начнем с простейшего случая, когда между системами нет интеграции.
То есть, представим ситуацию, когда в компании используются несколько независимых информационных систем: складская, бухгалтерская, CRM и финансовая. Между этими системами нет информационного обмена.
В результате для выполнения задачи по отгрузке товара, заявки в каждой системе заводятся отдельно и к примеру, менеджеры по продажам после выставления счетов клиентам вынуждены печатать их копии и нести в бухгалтерию. В бухгалтерии они регистрируются в бухгалтерской системе. Бухгалтерия регистрирует поступление денег на счет. Менеджеры по продажам, не имея возможность получить оплаты автоматически в CRM-систему, вынуждены ежедневно осведомляться в бухгалтерии о поступлении денег от клиентов.
Таким образом у нас образуется некоторый «Paper Net», то есть бумажный обмен данными между менеджерами, бухгалтерией и складом, а также двойная регистрация действий (один раз в складской системе, второй раз в бухгалтерской).
Кроме того, когда заявки в каждой системе заводятся вручную, то большую роль начинает играть человеческий фактор, то есть ошибки, допускаемые различными специалистами в процессе обработки заявок в системах.
Ну а кроме этого, весь этот бумажный документооборот довольно дорого обходится компании, так как приходится оплачивать затраты времени на выполнение дублирующихся процедур в разных системах и исправление допущенных ошибок.
Думаю, проблематика понятна, и можно перейти к рассмотрению способов интеграции.
Горизонтальная интеграция
Начнем с широко распространенного подхода горизонтальной интеграции – использованию сервисной шины. То есть, мы можем развернуть промежуточное ПО - так называемую корпоративную сервисную шину.
Данная шина должна выполнять задачи по хранению репозитория функционала тех корпоративных приложений, которые к ней подключены. При этом, шина должна обеспечивать возможность использования этих функций другими приложениями, также подключенными к этой шине. Взаимодействие между приложениями могут, например, происходить в форме обмена сообщениями или вызова опубликованных функций в виде REST API. Подключение системы к шине производится путем создании специального адаптера для каждой системы. После этого «опубликованные» функции системы становятся доступными другим подключенным системам.
Так, например, складская система при подключении к шине должна опубликовать свои функции по работе с позициями на складе. С помощью шины другие системы, например бухгалтерская, и CRM смогут использовать эти функции в своей работе. В свою очередь, складская система также, при необходимости использовать функции из других систем.
Взаимодействие между целевыми системами и шиной осуществляется с помощью специальных адаптеров и вот здесь кроется основная проблема, с которой может столкнуться архитектор при проектировании интеграции. Для разработки адаптера нам необходимо хорошо понимать, как работает та или иная целевая система, какие у нее есть функции и какие параметры необходимо передавать этим функциям для того, чтобы получить нужный результат. В общем, изучение данного процесса взаимодействия требует от архитектора серьезной аналитической проработки.
Но у горизонтальной интеграции есть и свои преимущества. Мы можем заменять конечные системы прозрачно для всего процесса взаимодействия с шиной. При этом никаких изменений в других системах не требуется. Нам необходимо только переработать адаптер для новой системы для того, чтобы она могла также публиковать свои функции в шине. То есть, мы можем заменить SAP на 1С просто переписав адаптер. Хотя, сделать это не всегда действительно “просто”.
Вертикальная интеграция
Альтернативой использованию шины является вертикальный подход к интеграции систем. В соответствии с этим подходом мы выделяем у интегрируемых систем набор экспертиз, которые нам необходимо интегрировать между собой.
Так, в примере ниже, мы выделены две экспертизы: оперативный учет и бухгалтерской учет. При этом бухгалтерский учет находится по вертикали выше складской системы и CRM. Соответственно, нижестоящие подсистемы поставляют данные подсистеме бухгалтерского учета.
Здесь мы также можем существенно сэкономить на бумажном документообороте и сопутствующих затратах на персонал. Но здесь также есть ряд недостатков.
Первым серьезным недостатком является сложность расширения функционала. Здесь в отличии от шины мы уже не можем ограничиться написанием адаптеров. Если нам необходимо к примеру, создать аналитическую систему, которая будет брать данные у находящейся выше в нашей иерархии системы Бухгалтерского учета, Но при этом, Аналитическая система будет использовать значительный объем данных от нижестоящих систем. В результате нам необходимо будет помимо разработки самой аналитической системы, также дорабатывать систему бухгалтерского учета, чтобы в аналитическую систему передавалась нужная информация.
Ну а во-вторых, любое изменение в рамках функционала одной системы неминуемо приведет к внесению изменений в вышестоящие системы, потому, что всегда есть возможности по интеграции в рамках одной функциональной экспертизы.
Интеграция «многие ко многим»
И третий, наиболее универсальный вариант интеграции, когда мы связываем системы между собой так как нам нужно, без использования иерархий и шины данных. То есть, в рамках данного подхода каждая из используемых в компании систем может при необходимости обращаться к функционалу любой другой системы, при этом каждая из них может также использоваться любой другой системой. То есть, у нас может быть как односторонняя связь, когда только одна система использует функционал другой, а может быть двусторонняя связь, когда обе взаимодействующие системы используют функции друг друга.
Здесь у нас, с одной стороны, нет тех ограничений, которые присутствуют в предыдущих двух подходах. Мы не привязаны к шине, которая является помимо прочего единой точкой отказа, так как выход из строя компонентов шины приведет к тому, что мы в принципе лишимся возможности взаимодействия между нашими системами, а каждый час простоя ИТ систем - это прямые убытки для компании.
Появление новой системы также для нас не будет большой проблемой, та как связывать ее придется только с теми системами, с которыми необходимо выстраивать взаимодействие.
И в целом, здесь возможности по интеграции ограничены только техническими ограничениями в самих целевых системах.
Но, чем мы платим за все эти преимущества? Связи типа многие ко многим сложно администрировать. Необходимо хорошо разбираться в структуре интеграции, потому что, изменение в одной системе влечет за собой переработку всего механизма взаимодействия между системами, так как старые вызовы функций перестанут работать. В целом, затраты на поддержку такой интеграционной схемы экспоненциально растут при увеличении числа интегрированных подсистем.
То есть, если у нас больше десяти интегрированных систем, то поддержка такой интеграции можем стоит недешево.
Когда интеграция не нужна
Возвращаясь логически к началу статьи, рассмотрим вариант, когда интеграция в принципе не нужна. Это идеальный случай с точки зрения эксплуатирующих ИТ служб, но для компаний интеграторов такой подход не очень интересен, так как на нем нельзя много заработать.
Если у нас для функционирования бизнес процессов используется модульная система от одного вендора, то процесс интеграции новой системы сводится к покупке необходимого модуля и его подключения к уже имеющейся экосистеме. Здесь процесс подключения модуля, как правило уже описан в инструкциях вендора и в случае возникающих проблем можно смело обращаться в их техподдержку.
Типичным недостатком такого подхода является зависимость от одного вендора. Так, если в портфеле компании разработчика нет какого-то нужного для нашего бизнес процесса решения, то нам придется либо начинать разводить “зоопарк” с другими решениями и интеграцией, или использовать Paper Net. Также, экосистема на основе решений одного вендора в плане лицензий стоит как правило дороже чем “зоопарк” из решений разных вендоров.
Заключение
В этой статье мы рассмотрели различные варианты интеграции ИТ систем. Важно понимать, что здесь нет "серебряной пули". Каждый вариант имеет свои достоинства и недостатки. Так, если у вас в компании имеется свой штат программистов, все системы хорошо задокументированы, то написание адаптеров для шины не будет большой проблемой. С другой стороны если вы давно используете модульное решение от одного вендора и оно вас полностью устраивает, то и не нужно в принципе связываться интеграцией.
Хочу пригласить вас на бесплатные уроки курса Enterprise Architect про основные понятия современной корпоративной архитектуры, а также про Hard Skills корпоративного архитектора. Регистрируйтесь по ссылкам выше, будет интересно.