Слишком часто об API думают позже

Вполне возможно, что ваша компания неправильно использует API. Ваша организация может объединить REST с API, и, поскольку они видят, что другие компании, добившиеся успеха, REST, все, что вам нужно сделать, это REST, и успех последует. Post hoc ergo propter hoc.

Это потому, что многие организации не понимают, что такое API. Успешные реализации API не увенчались успехом, потому что они использовали API. Они успешны, потому что создали отличный продукт и использовали API для распространения этого продукта. Стратегия API - это прежде всего создание отличного продукта.

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

Решение против продукта

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

API как решение

API как решение - это тактика, используемая для удовлетворения потребностей конкретного проекта. Это позволяет компьютерным системам связываться друг с другом. Часто он разрабатывается изнутри, то есть просто отражает внутреннюю реализацию приложения. Это дает очень небольшую ценность по сравнению с тем, что предлагал SOAP. Если / во время мозгового штурма, как разработать API, вы обнаружите, что ссылаетесь на то, как ваши ИТ-системы уже спроектированы, то вы наверняка находитесь в сфере API как решения.

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

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

API-интерфейсы как решения более похожи на внутренние инженерные проблемы, с которыми производители газонокосилок сталкиваются, но не раскрывают их клиенту. Возможно, у инженера-газонокосилки есть разные варианты подключения бензобака к двигателю. Один из вариантов может упростить производство для производственного отдела, тем самым сэкономив деньги компании или ускорив выпуск новой модели на рынок, но он не влияет на долгосрочную стратегию, как, например, разработка газонокосилки, которая не работает. Не нужна замена масла ». Точно так же вам может потребоваться быстрый способ подключения вашей HR-системы к вашей ERP-системе и создания быстрого API, который может привести вас к производству раньше, но это не API, который когда-либо продвигает корпоративную стратегию.

API как продукт

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

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

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

Успешная стратегия API

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

1. Рынок

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

2. Значение

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

3. Дорожная карта

Должен быть план того, куда должен идти API, чтобы отслеживать, куда движется его рынок.

4. Отзыв

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

5. Клиентский опыт

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

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

Потрясающий цифровой опыт

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

Документация

Наличие отличной документации означает, что она адаптирована для вашей аудитории, а не просто список файлов OAS. Документация должна быть четко разработана, чтобы минимизировать время, затрачиваемое разработчиком на работу, и достижение рабочего кода. Это означает, что он написан не разработчиками, а кем-то с опытом написания технических текстов.

Песочница

У разработчика должна быть "песочница", чтобы экспериментировать с API.

Подключение

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

Последовательность

Дизайн API должен быть интуитивно понятным и соответствовать другим вашим API. Хорошая аналогия - дизайн пользовательского интерфейса для веб-сайтов. Если попросить команду разработчиков спроектировать пользовательский интерфейс, получится пользовательский интерфейс, удобный для кода базового приложения, но неприятный и сложный для использования клиентами. Вот почему у нас есть профессионалы в области пользовательского опыта, которые разрабатывают пользовательские интерфейсы. Точно так же API, созданный для нужд кода приложения, будет неприятен и труден для использования разработчиками, не входящими в эту единую команду. Следовательно, дизайном API должен руководить не разработчик, а кто-то, ориентированный на конечного пользователя. В самом деле, Gartner говорит: «Программисты, занимающиеся проектированием API, - это противоположность стратегии API, которая разрабатывается для потребителя».

КПЭ

Наконец, для этого требуются ключевые показатели эффективности (KPI) для измерения опыта разработчика. Вы можете выбрать из множества вариантов. Сколько в среднем времени проходит от подключения к программе "hello world" и запуска приложения? Сколько телефонных звонков или электронных писем мы получили с просьбой о помощи? Сколько подписчиков у API? Какая рентабельность инвестиций в API? Количество запусков API в год? Это также означает, что вы отслеживаете, как новые выпуски API влияют на KPI, и реагируете на изменения в KPI.

Visa: пример отличного цифрового опыта

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

На главной странице у вас есть привлекательный экран приветствия, знакомящий вас с программой Visa API. Оттуда вы можете найти API-интерфейсы для различных ролей в бизнесе кредитных карт: продавцы, банки-эмитенты, банки-эквайеры и т. Д. Вы также можете изучить варианты использования.

Нажав на варианты использования, вы увидите многие из них, которые представляют ценность для индустрии кредитных карт: включите или выключите свою карту, установите уведомление о поездке, сгенерируйте динамические коды CVV2 и т. Д.

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

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

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

Менеджер по продукту API

Выявление рынка API, определение ценностного предложения API, создание дорожной карты API, разработка и управление процессом адаптации API, измерение KPI и бизнес-ценности API, а также получение отзывов от конечных пользователей API: это большая ответственность ! Как компании все это удается успешно реализовать? Все это возглавляет менеджер по продукту API.

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

Если вы пытаетесь реализовать стратегию API без менеджера продуктов API, учтите, что некоторые эксперты-аналитики прогнозируют, что к 2021 году 65% организаций, предоставляющих общедоступные API, установят роль менеджера продуктов API.

Ваши следующие шаги

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

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

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

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

Заключение

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

Если вы посмотрите на свои REST API и обнаружите, что задаетесь вопросом, чем они значительно отличаются от прежних SOAP-сервисов, возможно, вы находитесь в прежнем лагере: просмотрите рекомендации этой статьи и посмотрите, какие пробелы вам, возможно, придется заполнить, чтобы переместить вашу организацию. в последний лагерь.