Если своевременно не перейти от интеграции унаследованных приложений к использованию интерфейсов прикладного программирования (API) для соединения внутренних систем, это может привести к краху бизнеса, пишет на портале InformationWeek специалист по стратегии развития Google Global Platform Брайан Пагано.

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

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

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

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

API внутри предприятия

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

Объединение подразделений для более эффективной работы

Это, в сущности, та же проблема, что и подключение внешних пользователей. API могут предоставить уровень абстракции для объединения подразделений, создавая связи, которые не только обслуживают сегодняшние потребности, но и (в отличие от классических приемов интеграции) обеспечивают гибкость, позволяющую адаптироваться к меняющимся требованиям.

Укрепление безопасности

Предназначенный для разработчиков уровень API скрывает сложность систем, обеспечивая управление доступом и ведение журнала доступа ко всем системам.

Более эффективные операции

Во многих компаниях от ИТ-подразделений требуют делать больше меньшими силами. Использование понятной стандартной технологии вроде RESTful API позволяет компании подключать нужных людей к нужным инструментам.

Экономия средств

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

Как следует из сказанного выше, API могут быть полезны как внутри организации, так и вне ее, и все больше организаций обращают на это внимание.

«Мы применяем API в трех сферах, — сказал старший вице-президент телекоммуникационной компании West Corp Томас Скуио. — Во-первых, для наших внутренних операций. Во-вторых, для ускорения работы наших продуктовых команд с точки зрения консолидации на нашей платформе: каждый раз, когда мы видим дубликаты в своем портфеле или возможность закрепиться в определенных сегментах рынка, мы обычно создаем для этого API, а затем сокращаем выделяемые ресурсы. И, наконец, третья сфера — это отношения с внешним миром, в основном с нашими клиентами и партнерами, использующими созданные нашей организацией API».

Начало работы

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

Пусть каждая команда начнет добавлять к платформе свои API. Предприятиям не следует беспокоиться, если у каких-то команд еще нет своих API. API нетребовательны, их легко создавать и публиковать.

Потребуйте, чтобы команды обменивались информацией через API. Тогда им не придется изучать все причуды и тонкости работы друг друга. Не нужно будет понимать соглашения об именованиях, выбор технологий или структуры баз данных. Как внешние, так и внутренние API могут скрывать сложность. Конечно, если они унифицированы и ориентированы на разработчиков, а не просто на объединение систем.

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

Инвестируйте в платформу управления API. Такая платформа будет выполнять ключевые функции: кэширование, трафик, аутентификация/авторизация, защита, масштабирование, мониторинг и т. д. Многие решения доступны и сэкономят предприятиям время, деньги и ресурсы.

Откажитесь от унаследованной мышечной памяти. Почему так много компаний не улавливают различий между унаследованной интеграцией и API? Это мышечная память. Последние 15 лет были потрачены на интеграцию. Она вошла в словарь большинства ИТ-специалистов, для них интеграция — это зона комфорта. Проблема в том, что ИТ-подразделения должны решать проблемы не вчерашнего, а сегодняшнего дня, к которым относятся гибкость, масштабируемость, обмен информацией в масштабе Интернета. Построенная на API архитектура позволяет разрабатывать гибкие приложения, соответствующие требованиям новых технологий создания интерфейсов, развернутых в большом масштабе и легко подключаемых к другим системам на предприятии и вне его.

Конец централизованного управления сервисами. Распространение виртуализации, IaaS и PaaS, появление поколения интернет-разработчиков, которые легко могут получить доступ к серверным ресурсам, привели к отказу от централизованного управления сервисами, место которого заняло управление API, ориентированное на поддержку команд разработчиков приложений и гибкие децентрализованные архитектуры на базе API.

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

Как показано выше, API играют центральную роль в функционировании современных ИТ. В действительности они могут предоставить целый ряд преимуществ помимо обрисованных здесь. Например, в построенной на API архитектуре становятся излишними операции извлечения, преобразования и загрузки (ETL), потому что здесь каждое приложение отвечает за структурированное представление своих данных через API. Вытягивание и проталкивание (pull and push) данных построенного на базе API приложения обеспечивает обратную связь, которая может питать данными движки предсказательной разведки, способные обмениваться информацией с приложением через API для совершения дополнительных действий.

Сценарии использования и преимущества многочисленны, но главное в следующем: в условиях конкурентного рынка задержка с переходом от унаследованной интеграции к использованию API для объединения внутренних систем может привести к провалу.

Версия для печати