Интеграция

Логотип компании
Интеграция
Основная задача и красота интегрированных решений — своевременно и в полном объеме предоставить нужные данные потребителю.
Наверное, ни один современный ИТ-проект не обходится без интеграции. Более того, многие ИТ-системы на архитектурном уровне — «одна большая интеграция». Фактически без интеграции не было бы ИТ в их нынешнем виде. Апокалептично звучит, не так ли?

Все начинается с цели

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

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

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

Немного о технологии

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

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

Пора договориться

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

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

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

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

А теперь запишем

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

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

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

Шины данных и шинные решения

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

Проблема чистых данных

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

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

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

Правда, все не настолько печально: в том или ином виде проблема решается. И решается за счет приближения, когда задается некий разумный критерий (вероятностная оценка приближения), достижение которого позволяет говорить о чистоте данных. Например, если через интеграционный интерфейс проходит 100 000 записей в сутки, то, приняв критерий чистоты в 0,5%, мы допускаем, что 500 записей могут иметь изъяны на уровне логики. И если указанный порог не превышается, данные считаются чистыми.

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

Вместо заключения

Тема интеграции необъятна. У меня порой складывается ощущение (ложное, но кто знает, куда повернется технология в следующий миг?), что в какой-то момент все значимые системы одной отрасли так или иначе будут интегрированы. И тогда наступит не то Матрица, не то большое счастье. Ну и айтишникам прибавится работы: за таким хозяйством пойди уследи! Особенно если нужно обеспечить непрерывность, высокую производительность и доступность. 

Опубликовано 27.11.2012

Похожие статьи