Как мы боролись с феодализмом. Или что такое интероперабельность в разработке

Сегодня, я слушаю выпуск “Интероперабельность. Как подружить сервисы между собой” одного из моих любимых подкастов студии "Либо-Либо" — "Запуск завтра". Гость — Самата Галимова, активист в сфере цифровых прав, Кори Доктороу — делится опытом, как меняется законодательство в сфере допуска к закрытым системам Apple, FB и других технологических гигантов независимых разработчиков.
Я сразу вспомнил нашу борьбу за возможность клиента выбирать, какие системы они могут подключать к уже приобретенному ими ПО, и чтобы разработчики этого ПО не запрещали или не делали препоны для интеграций.
Мой опыт борьбы за интероперабельность
В 2016 году я присоединился к компании "Сервис Плюс" в роли руководителя направления. Компания специализировалась на разработке ПО для розничных сетей (ритейл). Моей задачей было вывести на рынок продукт "Управление программами лояльности для розничных сетей".
Работа нашего ПО LOYA строилась на базе кассового программного обеспечения, задача которого — своевременно печатать чеки, чтобы чек соответствовал законодательству, и оно это делало отлично. Но кассовое ПО не позволяло не программистам настраивать акции, а в нашем случае это маркетологи. Но это был супервостребованный функционал: нужно управлять маркетинговыми акциями, созданием персональных предложений, формировать профиль покупателя, проводить сегментацию, коммуницировать через доступные каналы и т. д., создавать различные пакеты предложений, объединяющих разные товары, и проводить анализ.
Эту программу мы сделали примерно за полгода. Далее начали активно продвигать её по всем нашим клиентам, которые использовали наше кассовое ПО. Но мы также продвигали её и клиентам, кто использовал кассовое ПО конкурентов. Здесь мы столкнулись с феодализмом, где были выстроены стены, рвы и выставлена стража в качестве специалистов, экспертов. Главная задача, которых была не допущать конкурентов.
В общем, вставал "вопрос интеграции" нашего программного обеспечения для управления лояльностью с кассовыми решениями конкурентов. А наши клиенты, розничные сети, хотели использовать наше решение. Мы умели продавать, но когда конкурент считает, что его ПО - это его вотчина, и не готов пускать никого, то придумывает тысячу причин, почему ты не хочет делать интеграцию с другими решениями.
Мы начали с ними встречаться с конкурентами: это были производители "Атол", ребята из Питера "Кристалл Сервис", разработчики на базе 1С и другие. Но каждый раз было много встреч, но еще больше отговорок: “Почему это нельзя сделать.” В итоге с рядом разработчиков мы смогли договориться, что у нас будет REST API, за доступ к которому нужно будет платить и получать поддержку, если вдруг что-то отвалится.Это наверно сейчас превалирующая практика умных разработчиков. Сразу приходят примеры на российском рынке движения разработчиков продуктов в сторону доступности SDK или возможностей интеграции с решениями вендоров для сторонних разработчиков+ Эвотор маркет+ Битрикс 24+ AMO.CRM

- Open Banking (Открытый банкинг): Директива PSD2 в Европе и аналогичные инициативы в других странах обязывают банки предоставлять API (интерфейсы программирования приложений), которые позволяют сторонним финтех-компаниям получать доступ к данным клиентов (с их согласия) и инициировать платежи. Это позволяет создавать новые инновационные сервисы, такие как приложения для управления личными финансами, агрегаторы счетов из разных банков, сервисы мгновенных платежей и т.д. Пример: Приложение Mint подключается к различным банковским счетам пользователя через API и предоставляет единую картину его финансового состояния.
- Платежные шлюзы и платформы: Такие компании, как Stripe, PayPal и Adyen, предоставляют API, которые позволяют интернет-магазинам и другим онлайн-сервисам интегрировать различные способы оплаты (банковские карты, электронные кошельки, местные платежные системы) в свои приложения и веб-сайты. Это обеспечивает бесшовный опыт для пользователей и расширяет возможности для бизнеса. Пример: Интернет-магазин может использовать API Stripe для приема платежей от клиентов по всему миру, независимо от того, какой банк или платежную систему они используют.
- Сервисы KYC/AML (Знай своего клиента / Противодействие отмыванию денег): Некоторые финтех-компании разрабатывают решения для проверки личности и соответствия требованиям по борьбе с отмыванием денег, которые могут быть интегрированы в другие финансовые приложения через API. Это позволяет компаниям быстро и эффективно проводить проверки, не разрабатывая собственные сложные системы. Пример: Сервис Sumsub предоставляет API для верификации личности, который может быть использован банками, криптовалютными биржами и другими финтех-компаниями.
- Интеграция с бухгалтерским ПО: Многие финтех-сервисы, такие как приложения для выставления счетов и управления расходами, интегрируются с популярным бухгалтерским программным обеспечением (например, QuickBooks, Xero) через API. Это позволяет автоматически передавать финансовые данные между системами, упрощая бухгалтерский учет и отчетность. Пример: Приложение Expensify автоматически экспортирует данные о расходах сотрудников в бухгалтерскую систему компании.
Другие технологические компании:
- Интеграция социальных сетей: Возможность делиться контентом из одного приложения в другое (например, из Instagram в Facebook или Twitter) является примером интероперабельности на уровне приложений. API социальных сетей позволяют сторонним разработчикам интегрировать их функциональность в свои приложения. Пример: Приложение для редактирования фотографий может позволить пользователям напрямую публиковать обработанные изображения в различные социальные сети через их API.

- Мессенджеры и протоколы обмена сообщениями: Хотя полная интероперабельность между различными мессенджерами (например, WhatsApp, Telegram, Signal) пока не достигнута, существуют инициативы и протоколы (например, Matrix) направленные на создание открытых стандартов для обмена сообщениями, которые могли бы позволить пользователям общаться между разными платформами.
- Облачные сервисы и API: Провайдеры облачных услуг, такие как Amazon Web Services (AWS), Microsoft Azure и Google Cloud Platform (GCP), предоставляют множество API, которые позволяют разработчикам интегрировать различные сервисы (хранение данных, вычисления, машинное обучение и т.д.) в свои приложения. Это позволяет создавать сложные и масштабируемые решения, комбинируя сервисы от разных поставщиков. Пример: Веб-приложение может использовать сервис хранения данных AWS S3, базу данных Google Cloud SQL и сервис машинного обучения Azure Machine Learning, взаимодействуя с каждым из них через соответствующие API.
- Умные устройства и экосистемы: Развитие стандартов, таких как Matter, Zigbee, Z-Wave и т.д. направлено на обеспечение интероперабельности между устройствами умного дома от разных производителей. Это позволит пользователям управлять различными устройствами (освещение, термостаты, замки и т.д.) через единое приложение или голосового помощника, независимо от бренда.
Эти примеры демонстрируют, как интероперабельность программного обеспечения позволяет создавать более гибкие, инновационные и удобные решения для пользователей и бизнеса, преодолевая "феодализм" закрытых экосистем.
Комментарии 3
Авторизуйтесь чтобы оставить комментарий
Бибигуль Кандарбекова · Март 31, 2025 11:52
Ваши размышления о интероперабельности и борьбе за открытость систем очень актуальны.
Dmitry Vatyutov · Март 31, 2025 14:13
Бибигуль, добрый день. Спасибо. Поделитесь вашим опытом в этом вопросе?
Еламан Армия · Март 25, 2025 01:07
👍