Критерии межсистемной интеграции

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

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

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

Другими важными ограничениями которые следует учитывать являются:

• Связанность приложений (application coupling) – даже проинтегрированные приложения должны стремиться минимизировать их зависимость друг от друга с тем, чтобы не осложнять их дальнейшее независимое развитие. Сильносвязанные приложения делают различные допущения и предположения о работе друг-друга, тем самым сильнее прявязываясь к внутренним структурам друг-друга. Это приводит к ситуациям, при которых изменения в одном из приложений порождает цепную реакцию изменений, которые необходимо провести в связанных приложениях, что резко усложняет развитие всего интеграционного решения. Интерфейсы по которым проходит интеграция должны быть достаточно специфичными с тем чтобы позволять реализовать необходимую функциональность и в то же время достаточно общими (general), чтобы позволять относительно свободно изменять их реализацию.
• Интеграционная сложность (integration simplicity) – реализуя задачу интеграции, разработчики должны стремится минимизировать изменения в интегрируемых приложениях и минимизировать количество кода (и его сложность) необходимого для реализации интеграционного решения. На практике такое далеко не всегда удаётся, и подход, предполагающий наименьшее вмешательство в исходные коды приложений может не давать требуемого результата.
• Интеграционная технология (integration technology) - различные интеграционные подходы требуют использование различных технологических платформ, специализированного программного и аппаратного обеспечения. Всё это может вносить существенный вклад в конечную стоимость интеграционного решения и должно приниматься в расчёт при выборе того или иного способа интеграции.
• Формат данных (data format) – интегрируемые приложения могут соглашаться и работать в одном формате. Альтернативой является создание некоего общего промежуточного формата данных, не являющегося специфичным для какого либо конкретного приложения. Это может позволить отвязать приложения от формата данных и упростить дальнейшее независимое их развитие.
• Интеграция данных или интеграция функциональности – интегрируемые приложения могут ограничиться лишь разделением или обменом данными, не посылая и не принимая никаких команд друг от друга. Помимо этого, приложения могут предоставлять друг другу (экспортировать) некую оговоренную функциональность. Экспорт функциональности обычно оказывается более труднодостижимым так как порождает целый ряд смежных задач связанных с:
• удалённым вызовом процедур (или подобными механизмами)
• обеспечения безопасности
• синхронизации вызовов (проблема синхронных вызовов и сложность реализации асинхронных)
• Допустимое запаздывание данных (data timeliness) – проходит некоторое время между моментом когда одно приложение генерирует данные и моментом времени, когда эти данные становятся доступными для другого приложения. Это требование должно быть учтено при выборе технологии интеграции и её вариантов и настроек (например периоды времени через которые происходит выгрузка данных из одной системы и загрузка в другую).

Дата добавления: 2014-01-05