Проблемы интеграции облачных сервисов на примере AmoCRM, JivoSite и LPGenerator

Часть 2

Соображения

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

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

Потребители обоснованно ожидают, что интеграция – это пустяки и легко решаемый вопрос. При использовании CRM было бы идеально иметь готовую и дешевую интеграцию между сервисами, которая не создавала бы множественное толкование. Возможно, ИТ-архитекторам стоит поломать голову над тем, как подготовить облачную шину для организации дешевой и удобной интеграции между облачными сервисами. К примеру, была, такая облачная шина Cast Iron, которая некоторое время назад была приобретена IBM. Простые варианты интеграции, где необходимо передавать данные для аналитики, реализованы во всех аналитических инструментах, таких как PowerBI, QlickView, Tablou и пр.

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

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

Рекомендации

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

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

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

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

comments powered by HyperComments
Share