The post has been translated automatically. Original language: Russian
Today, I'm listening to the issue of “Interoperability. How to make friends between services” of one of my favorite podcasts of the Either-Or studio — "Launch tomorrow". The guest, Samata Galimova, an activist in the field of digital rights, Cory Doctorow, shares her experience of how legislation is changing in the field of access to closed systems of Apple, FB and other technology giants of independent developers.
I immediately remembered our struggle for the client's ability to choose which systems they can connect to the software they have already purchased, and so that the developers of this software do not prohibit or create obstacles to integrations.
My experience of fighting for interoperability
In 2016, I joined the company "Service Plus" as the head of the department. The company specialized in software development for retail networks (retail). My task was to bring the product "Loyalty Program Management for retail chains" to the market.
Our LOYA software was based on cash register software, whose task is to print receipts in a timely manner so that the receipt complies with the law, and it did it perfectly. But the cash software did not allow non-programmers to set up promotions, and in our case it was marketers. But it was a super-demanded functionality: you need to manage marketing campaigns, create personal offers, create a customer profile, segment, communicate through available channels, etc., create various packages of offers combining different products, and conduct analysis.
We completed this program in about six months. Then we started actively promoting it to all our clients who used our cash register software. But we also promoted it to customers who used our competitors' cash register software. Here we are faced with feudalism, where walls, moats were built and guards were deployed as specialists, experts. The main task was to keep competitors away.
In general, there was a "question of integrating" our loyalty management software with competitors' cash solutions. And our customers, retail chains, wanted to use our solution. We knew how to sell, but when a competitor thinks that his software is his fiefdom and is not ready to let anyone in, he comes up with a thousand reasons why you don't want to integrate with other solutions.
We started meeting with competitors with them.: these were the Atol manufacturers, the guys from St. Petersburg, Crystal Service, 1C-based developers, and others. But each time there were many meetings, but even more excuses: “Why can't this be done?” As a result, we were able to agree with a number of developers that we would have a REST API, for access to which we would need to pay and receive support if something suddenly fell off.This is probably the prevailing practice of smart developers right now. Examples immediately come up in the Russian market of the movement of product developers towards SDK accessibility or integration with vendor solutions for third-party developers+ Evotor market+ Bitrix 24+ AMO.CRM
- Open Banking: The PSD2 Directive in Europe and similar initiatives in other countries oblige banks to provide APIs (application programming interfaces) that allow third-party fintech companies to access customer data (with their consent) and initiate payments. This allows you to create new innovative services such as personal finance management applications, account aggregators from different banks, instant payment services, etc. Example: The Mint application connects to various user bank accounts via the API and provides a unified picture of the user's financial condition.
- Payment gateways and platforms: Companies such as Stripe, PayPal and Adyen provide APIs that allow online stores and other online services to integrate various payment methods (bank cards, electronic wallets, local payment systems) into their applications and websites. This provides a seamless experience for users and enhances business opportunities. Example: An online store can use the Stripe API to accept payments from customers around the world, regardless of which bank or payment system they use.
- KYC/AML (Know Your Customer/Anti-Money Laundering) Services: Some fintech companies are developing identity verification and anti-money laundering compliance solutions that can be integrated into other financial applications via APIs. This allows companies to conduct inspections quickly and efficiently without developing their own complex systems. Example: The Sumsub service provides an API for identity verification that can be used by banks, cryptocurrency exchanges, and other fintech companies.
- Integration with accounting software: Many fintech services, such as billing and expense management applications, integrate with popular accounting software (e.g. QuickBooks, Xero) via APIs. This allows you to automatically transfer financial data between systems, simplifying accounting and reporting. Example: The Expensify application automatically exports employee expense data to the company's accounting system.
- Facebook Instagram Integration: The ability to share content from one app to another (for example, from Instagram to Facebook or Twitter) is an example of application-level interoperability. Social media APIs allow third-party developers to integrate their functionality into their applications. Example: A photo editing application can allow users to directly post processed images to various social networks through their API.
- Messengers and messaging protocols: Although full interoperability between different messengers (for example, WhatsApp, Telegram, Signal) has not yet been achieved, there are initiatives and protocols (for example, Matrix) aimed at creating open standards for messaging that could allow users to communicate between different platforms.
- Cloud Services and APIs: Cloud service providers such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) provide many APIs that allow developers to integrate various services (data storage, computing, machine learning, etc.) into their applications. This allows you to create complex and scalable solutions by combining services from different vendors. Example: A web application can use the AWS S3 data storage service, the Google Cloud SQL database, and the Azure Machine Learning service, interacting with each of them through the appropriate APIs.
- Smart devices and ecosystems: The development of standards such as Matter, Zigbee, Z-Wave, etc. is aimed at ensuring interoperability between smart home devices from different manufacturers. This will allow users to control various devices (lighting, thermostats, locks, etc.) through a single application or voice assistant, regardless of the brand.
These examples demonstrate how software interoperability allows for more flexible, innovative, and user-friendly solutions for users and businesses, overcoming the "feudalism" of closed ecosystems.
Сегодня, я слушаю выпуск “Интероперабельность. Как подружить сервисы между собой” одного из моих любимых подкастов студии "Либо-Либо" — "Запуск завтра". Гость — Самата Галимова, активист в сфере цифровых прав, Кори Доктороу — делится опытом, как меняется законодательство в сфере допуска к закрытым системам 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 и т.д. направлено на обеспечение интероперабельности между устройствами умного дома от разных производителей. Это позволит пользователям управлять различными устройствами (освещение, термостаты, замки и т.д.) через единое приложение или голосового помощника, независимо от бренда.
Эти примеры демонстрируют, как интероперабельность программного обеспечения позволяет создавать более гибкие, инновационные и удобные решения для пользователей и бизнеса, преодолевая "феодализм" закрытых экосистем.
Share
