Post #385

Ладно, какие я знаю способы классификации интеграций: 🔹по предмету, что именно интегрируем: данные, документы, справочники, функции? Вот у нас есть две или несколько систем. Мы хотим чтобы что из одной системы оказалось в другой? Появились какие-то данные? Или документ из одной системы можно было бы открыть в другой? Или чтобы в обеих системах были одинаковые справочники и актуальная основная информация? Или чтобы функциями одной системы можно было воспользоваться в другой? 🔹по "глубине": что значит "появились"? Можно просто посмотреть данные/документы, или с ними можно что-то сделать? Сделать через интерфейс, или программно? Вот я сейчас вожусь с Битрикс24 (не спрашивайте), и там многие "интеграции" выглядят так: да, теперь можно посмотреть в интерфейсе Битрикса данные из другой системы. Нет, использовать их в процессах или, например, привязать к карточке сделки/клиента — нельзя. Только посмотреть. Вот такая интеграция. Соответственно, можно рассмотреть "глубину" интеграции: те данные, документы, справочники и функции, которые вы получаете из другой системы — они насколько глубоко интегрированы в вашу систему? Практически так же, как нативные объекты, или живут в ограниченных контекстах, или существуют в совсем отдельных изолированных "резервациях", или просто точечно используются по месту, почти не проникая в вашу систему? 🔹по уровню: об интеграции чего мы говорим? Объектов и модулей внутри одной системы? (Например, многослойная архитектура, API между бэкендом и фронтендом). Или интеграции нескольких систем/сервисов в рамках одного подразделения, с одним владельцем? Систем из разных департаментов с разными владельцами и политиками? Систем из разных организаций? Тут речь идёт о подконтрольности систем и наших возможностях диктовать правила взаимодействия и вносить изменения в системы. Рядом с этим делением идёт категоризация интеграций на внутренние и открытые (в основном говорят про внутренние и открытые API). У них могут быть совершенно разные требования по безопасности, производительности, надежности, обратной совместимости и т.п. Вплоть до маркетинга внешних API и управления сообществом разработчиков — вот где уникальные люди, мы, помню искали таких, и их в России по пальцам можно пересчитать. 🔹по топологии: ну, тут понятно: точка-точка, звезда, шина, последовательное соединение (pipes-and-filters). 🔹по "стилю" (из книжки "Паттерны интеграций корпоративных приложений") — не совсем классификация, поэтому авторы и называют эти стилями: файловый обмен; общая база данных; вызов удаленной процедуры (включая сюда и REST!); асинхронный обмен сообщениями. 🔹по предмету коммуникации, что именно мы отправляем: объект данных? документ? событие? Это разные стили и даже разные архитектуры. 🔹по цели, очевидно: мы чего хотим от интеграции? Ускорения? Увеличения гибкости? Улучшения качества данных? Снижения расходов? Для чего всё затевается? 🔹по "аспекту", я не придумал лучшего слова. Про какой аспект информационных систем мы думаем в первую очередь, что хотим объединить? Возможно, эту классификацию можно объединить с первой, про объекты. Итак, аспекты: данные (в любом виде, включая документы), системы (имея в виду, в первую очередь, взаимозаменяемость и унифицированность интерфейсов), процессы/функции/сервисы, UI/UX (унификация и консистентность пользовательского опыта), инфраструктуры, безопасности. Дальше идет несколько классификаций отдельных подходов к интеграциям, зачастую просто выборов из двух вариантов или их смеси, не знаю, тянет ли это на отдельные классификторы: - централизация или стандартизация? - оркестрация или хореография? - синхронное или асинхронное взаимодействие? - от данных или от функций (ресурсы vs методы, REST vs RPC)? - CA, CP или AP? - at least once, at most once или exactly once? - бинарные данные или человекочитаемые? - шифрование канала или каждого сообщения? Вот что первым приходит в голову, когда мы говорим о классификации интеграций, наверняка есть ещё что-то, о чем я забыл и что не укладывается ни в какую классификацию. Пишите в комменты, обсудим!