Сегодняшний мир держится на интерфейсах прикладного программирования — API. С ними стало возможным получать данные и потреблять услуги через веб-приложения, мобильные приложения и устройства, подключенные к сети. Все чаще взаимодействие в интернете выполняются именно через API. Благодаря API появляются новые модели ведения бизнеса, а интернет стал универсальной бизнес-платформой.
API не имеет индустриальной привязки, компании из разных сфер экономики видят в их использовании ценность для своего бизнеса. В свою очередь, рынок программного обеспечения для управления API стремительно развивается, об этом свидетельствуют отчеты Gartner и Forrester.
Всего несколько лет назад взаимодействие между разными подразделениями одного и того же бизнеса обычно обеспечивалось через интеграционную шину. Но модель взаимодействия через API-портал — портал, на котором публикуются API — оказалась настолько удобной, что теперь ее используют и внутри компаний.
Как же получилось, что, даже выбирая модель взаимодействия между подразделениями, компании склоняются сегодня к решениям на основе API? В чем суть актуальной технологической модели и каковы новые правила игры?
Открытые API — мода или необходимость?
Использование открытых API — не просто мода или веяние времени, это ответ на требования рынка. Банки, телекоммуникационные компании и страховые организации уже публикуют свои сервисы для внешнего пользования, для интеграции с партнерами и для автоматизации финансовых потоков. Похоже, недалек тот день, когда к ним присоединятся поставщики развлечений, эксплуатационных сервисов и физических товаров .
В Европе интерес к инновациям в области финансовых потоков поддержала платежная директива Европарламента PSD2, выпущенная для создания более равномерного, прозрачного и открытого рынка платежей, который будет содействовать инновациям, конкуренции и безопасности. В России развитие открытых API официально признано ключевым элементом, необходимым для эффективной интеграции систем участников финансового рынка.
Российское государство и его финансовый сектор уже осознали необходимость открытого банкинга. Предоставление банковских API внешним организациям признано ключевым элементом, необходимым для эффективной интеграции систем участников финансового рынка, инициативы выпуска открытых API поддерживают Центробанк, портал Банки.ру, Московская биржа, «Национальный клиринговый центр» и «Национальный расчетный депозитарий». Отдельные банки уже сформулировали свою стратегию открытого банкинга, определились с моделью дальнейших действий, официально анонсировали доступ к своим системам и сервисам через открытые API и приступили к соответствующим работам.
Отечественные операторы мобильной связи тоже предлагают новые платформы с API для развития бизнесов своих партнеров. Это позволит телекоммуникационным провайдерам поддерживать своих партнеров, объединяя их предложения и расширяя для них рынок сбыта.
Российские банки и телекоммуникационные провайдеры — это именно те предприятия, которые первыми осознали себя как разработчики программного обеспечения, а рынок — как большую цифровую платформу для управления продуктами, настройки маркетинговых акций и взаимодействия с потенциальными клиентами. Продуктовые команды, заказчики, компании и клиенты понимают, что чем более открытыми они будут, тем более открытыми будут их продукты, и тем быстрее они будут интегрироваться в общую экосистему тех рынков, на которых они работают. Поэтому они и используют открытые API — разумный и эффективный способ взаимодействия разработчиков, который позволяет драматически сократить время выхода новых продуктов на рынок.
Кроме того, открытые API представляют своим партнерам такие разработчики программного обеспечения, как «Яндекс». Почта России тоже предлагает интеграцию с внешними приложениями через API, что позволяет встроить сервисы Почты России в сторонние сайты, приложения, системы учета и документооборота — например, добавлять на сайты функции отслеживания отправлений.
И, конечно, создание продуктов с открытыми API естественно для самих разработчиков программного обеспечения, таких как Software AG. Чем полнее их продукты будут документированы и чем лучше они будут управляться, тем больше будет у них пользователей.
Но управление открытыми API никому не дано свыше. Оно невозможно без соответствующего технологического стека.
Кто разрабатывает API-платформы и как они работают
Согласно вышеупомянутому «волшебному квадранту» агентства Gartner, лидерами на рынке систем управления полным жизненным циклом API являются компании Google, CA Technologies, IBM, Software AG, MuleSoft, Red Hat и TIBCO Software. Агентство Forrester в своем недавнем исследовании называет лидерами компании IBM, Google, Software AG, Rogue Wave Software и WSO2.
Согласно отчету Forrester: «API являются ключевой основой для цифровой трансформации. Они способствуют оптимизации клиентского опыта, создают интегрированные цифровые экосистемы клиентов и партнеров, позволяют компаниям извлекать выгоду из прорывных цифровых инноваций, повышать операционную эффективность и закладывают основу для платформенных бизнес-моделей… Решения для управления API играют центральную роль в управлении отношениями между поставщиками и пользователями API, разработчики и поставщики приложений должны рассматривать их как бизнес-приложения, исключительно важные для успеха цифрового бизнеса».
«Не обеспечив полноценного управления жизненным циклом API, нельзя создать платформу для цифровой стратегии, построить экосистему и запустить эффективные продукты», — добавляет в своем отчете Gartner.
Что же обеспечивают системы для управления полным жизненным циклом API? Обычно в технологический стек управления жизненным циклом API входят средства публикации API на удобном для чтения портале, основным пользователем которого являются сторонние разработчики, среда эксплуатации, потребления, обслуживания, управления версиями API и средства их вывода из эксплуатации. Некоторые разработчики (в их числе Software AG) предоставляют также средства планирования, проектирования, внедрения и тестирования API.
Мы в компании Software AG занимались управлением API, когда это еще называлось «внутренним взаимодействием». Мы расширяли и совершенствовали связующее программное обеспечение, решения для интеграции приложений, системы для создания сервисной шины предприятия и инструментарий для создания систем, основанных на сервисно-ориентированной архитектуре.
В 2004 г. в дополнение к нашей интеграционной шине мы создали продукт B2B Trading Networks, предназначенный для межпартнерского взаимодействия и обмена данными. В нем были реализованы вполне классические пользовательские сценарии межпартнерского взаимодействия, включая постоянный мониторинг, сервис, обмен данными по итогам операционного дня. Тогда это еще не называлось открытыми API.
Наконец, пять лет назад мы представили полный жизненный цикл управления API в рамках платформы управления API webMethods. В 2014 г. мы запустили webMethods API Portal для разработчиков API, а в 2016 г. объединили функционал API-шлюз webMethods API Gateway, портала и средств медиации и управления жизненным циклом в одну платформу. Эти средства поддерживают разработку API, их сборку, одобрение и публикацию в принятом технологическом стандарте и являются частью платформы Software AG Hybrid Integration & API.
Как выбрать API-платформу
Агентство Forrester считает, что при выборе решения для управления API нужно, в первую очередь, учитывать, является ли предлагаемое решение комплексным — то есть содержит портал для разработчиков API, портал для управления API и API-шлюз. Особо отмечено, что некоторые решения предоставляют дополнительные компоненты, такие как инструменты проектирования и разработки API, интеграционные платформы, платформы управления услугами в режиме реального времени и т. п.
Далее Forrester подчеркивает, что решение для управления API должно быть настоящим автономным продуктом, отделяемым от любых связанных с ним платформ, интеграционных продуктов или бизнес-приложений.
Наконец, авторы отчета считают, что стоит доверять тем разработчикам решений, которые имеют ряд полноценных внедрений. Клиентами решения Software AG для управления API являются Michael Kors (производитель и поставщик одежды и аксессуаров высокого класса), American Electric Power (одна из крупнейших североамериканских энергетических компаний), Outerwall (поставщик автоматизированных киосков для розничных продаж), Dick’s Sporting Goods (розничная сеть спортивных товаров), EDF (крупнейшая французская государственная энергогенерирующая компания и крупнейшая в мире компания-оператор атомных электростанций) и др.
К этому списку параметров стоит добавить еще несколько факторов, которые необходимо принимать во внимание при выборе API-платформы.
1. В разных отраслях экономика работает по-разному и имеет разные схемы монетизации. Оцените план развития API-платформы, которую вы рассматриваете. Отражает ли она реалии вашего сегмента бизнеса? Важно определить бизнес-задачу внедрения, сформировать список бизнес-требований к решению и из него вывести список функциональных и архитектурных требований. Возможно, этот список определит выбор не только API-решения, но и дополнительных компонентов.
Управление политиками API
2. Очень важно, чтобы ваша API-платформа соответствовала ожиданиям ваших заказчиков, а точнее — их ИТ-отделов. Платформа должна быть удобна для внедрения и работы, она должна поддерживать комфортную для заказчиков технологическую модель развертывания (облачную, на физических ресурсах или гибридную), ее функциональность должна соответствовать их текущим потребностям, а план ее развития — их будущим потребностям на год или два вперед.
3. API-портал должен иметь широкие возможности аналитики, тестовые интерфейсы для разработчиков, возможность генерировать документацию на основе метаданных API. Он должен обеспечивать социальное сотрудничество разработчиков, генерацию клиентских SDK и средства монетизации.
Генерация клиентских SDK
4. API-шлюз должен обеспечивать безопасность (аутентификацию, авторизацию, управление политиками безопасности, защиту от атак), медиацию сервисов, возможности маршрутизации и балансировки нагрузки.
5. Средства управления жизненным циклом API должны обеспечивать и оценивать взаимосвязь внутренних и внешних сервисов, микросервисов и обычных служб, технических и бизнес-сервисов, а также поддержку разных типов «активов» в каталоге.
6. Очень важен вопрос общей стоимости владения решениями, которая зависит от скорости разработки продуктов и времени их вывода на рынок — а на это влияют и практики, принятые у разработчиков, и используемые ими технологии.
7. Вопрос, на который у разработчиков API-платформ часто нет ответа — каким образом будет создаваться контракт между заказчиком и партнером и как будет работать биллинг – скорее всего у вендора есть рекомендации по реализации технологической возможности создания контракта.
* * *
Что ж, на самом деле в API нет ничего нового — просто раньше они были внутренними. Из-за сегодняшней волны интереса к API многим уже кажется, что этой аббревиатурой всегда обозначались способы взаимодействия компаний через интернет, но на самом деле API предоставляют способы взаимодействия продуктов, технологических сервисов и их потребителей, которые могут принадлежать как разным игрокам рынка, компаниям и заказчикам, так и разным бизнес-группам внутри компании.
Наш интеграционный продукт существует и развивается много лет, он стабилен и зрел, его используют многие заказчики. Чтобы оценить его самостоятельно, посетите нашу веб-страницу бесплатного тестового программного обеспечения, где вы легко найдете различные компоненты платформы webMethods. Протестируйте webMethods API Cloud Free Trial прямо сейчас и расскажите нам о своих впечатлениях.
