API: что вас сюда привело?
Нам нужно поговорить об API в последний раз. API великолепны. Они объединяют предприятия, способствуют внедрению инноваций, повышают эффективность и обеспечивают основу электронной коммерции. Но то, как мы делаем API, не подлежит ремонту.
Я все время это вижу. Вы представляете малый или средний бизнес, и опыт работы с API может вас не беспокоить. Освоение API - не ваша работа. Таким образом, вы составляете свой API, следуя за вашим любимым влиятельным лицом и используя (желательно бесплатные) готовые продукты.
Или вы крупное предприятие. Вы даже не знаете, сколько у вас API. Нет представления о том, какие возможности компании имеют цифровой интерфейс, ведущий к разрозненности, разобщению, дублированию и трудному сотрудничеству.
В любом случае, результатом является неконтролируемый беспорядок, который приводит к потере времени и денег на тщетные попытки исправить это только для того, чтобы найти нового конкурента или теневые ИТ-службы заменили вас.
Что еще хуже, так это подход большинства пользователей. Вы клиент API. Вы не рассматриваете использование API как зависимость или ответственность. Никаких контрактных тестов, никакого плана Б на случай отказа API и никакой отказоустойчивости. Просто слепо верю, что провайдер всегда будет рядом и интерфейс менять не будет.
За пределами круга экспертов по API я еще не встречал человека, который бы любил создавать или использовать API. Я не встречал ни одного человека, которому нравилось бы читать документацию по API (или писать, за исключением технических писателей). Я не слышал ни о ком, кто любит порталы для разработчиков или любит изучать HTTP. Черт возьми, кто вообще способен понять HTTP! Кто должен быть на связи, когда API перестает работать, когда происходит сбой интеграции с API.
А что касается безопасности? Вам нужны знания в пределах экспертизы, чтобы сделать это частично правильно. Или вы можете приобрести дорогое сложное программное обеспечение для управления API и надеяться, что они помогут или обучат вас.
«Во всем мире только 15% сотрудников заняты своей работой».
- Джим Клифтон
На дворе 2020 год, и создание и использование API-интерфейсов является медленным, дорогостоящим, утомительным и подверженным ошибкам, что приводит к хрупкости систем. Это ответственность и всегда соображение безопасности. В 2020 году API полагаются на надежду.
Тем не менее, предприятиям необходимо подключаться к цифровым технологиям больше, чем когда-либо. В условиях глобального потрясения 2020 года и стремительного роста количества домашних офисов ранее немыслимые вещи теперь переходят на цифровые технологии. Все это тихо собрали вместе отважные люди, которые вручную подключали системы и не ложились спать допоздна, чтобы поддерживать связь.
Но у нас недостаточно этих героических людей, чтобы бороться с стремительно растущей сложностью и растущим спросом. И даже если бы мы это сделали, они смогут работать только так быстро, все еще совершая ошибки. Кроме того, разве не было бы удивительно, если бы они могли сосредоточиться на бизнес-задачах вместо того, чтобы непрерывно прокладывать и менять кабели на распределительном щите?
Более того, большинство компаний думают, что организация с цифровой трансформацией - это в лучшем случае отправка электронных писем, использование Microsoft Office и внедрение Salesforce CRM. Их цифровое присутствие заканчивается наличием веб-сайта и цифрового маркетинга.
Такой образ мышления никуда не годится в мире, связанном с искусственным интеллектом. Боты, как и любая другая компьютерная программа, не могут обрабатывать электронные письма или веб-сайты. Как будет механический цех? Как машина найдет и узнает что-то?
То, что привело нас сюда, не приведет к дальнейшему
Компании, понимающие важность цифрового интерфейса для своего бизнеса, тратят много денег и усилий на запуск программ API. Те, кто не может внедрять инновации, выпускать новые продукты и действовать эффективно. Часто агрегатор доменов или стартап виртуализируют действующего оператора, направляя его в небезопасное положение.
Мы создали технологии для смягчения некоторых проблем, используя тщательную автоматизацию, стандартизацию и управление на основе форматов описания API, таких как OpenAPI Spec, AsyncAPI Spec или GraphQL Schema. Но это невероятно сложно для экспертов, не связанных с API, требующих постоянной приверженности и дисциплины.
Тогда есть открытие. Вам нужен портал для разработчиков или хотя бы каталог API. Если ваше предложение является публичным, вам нужно заплатить Google, чтобы он играл вместе с SEO и проводил всевозможные маркетинговые мероприятия, чтобы люди могли даже заметить вас и ваш бизнес-интерфейс.
Но как управление, так и открытие через Интернет проистекают из того же мышления, которое привело нас к этому.
«Мы не можем решить наши проблемы, используя то же мышление, которое мы использовали, когда создавали их».
- Альберт Эйнштейн
Ирония заключается в том, что ни одна из этих проблем, затрат, потраченного времени, упущенных деловых возможностей и разочарованных людей не должна быть здесь.
Все, что нужно, - это изменить мышление:
Что, если бы программы могли обнаруживать другие программы и подключаться к ним самостоятельно, а не заставлять людей делать это? *
Конечно, программы также будут поддерживать соединение и при необходимости адаптироваться, в результате чего практически не потребуются затраты на обслуживание.
Вот и все.
Войдите в superface.ai, цифровой интерфейс для бизнеса, где организации могут публиковать свои возможности в свободное время с минимальными затратами, а их клиенты могут обнаруживать и подключаться за миллисекунды.
Совершенно верно, подключение к новому API может занять долю секунды вместо недель работы и бесконечного обслуживания. Superface снижает затраты на предоставление API на две трети и дополнительно снижает затраты на интеграцию до 99,99%. Все это, чтобы вы могли сосредоточиться на своем бизнесе и приложении и больше никогда не беспокоиться об API.
Что бы вы создали, если бы могли мгновенно подключиться к любому потенциалу в своей организации или на этой планете? Дайте мне знать!
Ваш,
— Z.
* Здесь также есть деловой аспект, о котором я расскажу в отдельном посте.
