Header Ads Widget

Ticker

6/recent/ticker-posts

6 razones para no adoptar API (desacreditadas)



En algunas empresas, conseguir la aceptación empresarial de una estrategia API completa puede ser un desafío inmenso. Los propietarios de productos con visión de futuro se encuentran con muchos obstáculos por parte de las partes interesadas: "siempre lo hemos hecho de esta manera", "es demasiado arriesgado" o "¿no tenemos ya una API?", Entre otros.

En este artículo, veremos seis razones para no adoptar API . Si bien estas explicaciones a veces pueden ser válidas, generalmente son solo excusas. Como resultado, también exploraremos cómo puede refutar estos argumentos, refiriéndonos a los consejos de María García, estratega de innovación y directora de programas de Amadeus.

Charla de María García en la Cumbre de la Plataforma Nórdica de APIs 2019 . Para escuchar más información práctica sobre cómo puede liderar la transición de su organización hacia una cultura de API abierta, vea la charla completa aquí:

1 - "Siempre lo hemos hecho de esta manera"

Los viejos hábitos son quizás la principal causa de resistencia a la adopción de API. Podría pensar que este era un problema mayor a mediados de la década de 2000, cuando las API web aún tenían que demostrar su valía, pero los viejos hábitos siguen siendo una parte importante de nuestro proceso de toma de decisiones. Hace solo unos años, cuando buscaba aumentar el consumo interno de API en Danske Bank , el propietario del producto API, John Madsen, identificó los viejos hábitos como un gran revés. “Puedes presentar algo que es completamente nuevo […] pero la gente realmente no quiere cambiar tanto”, dice.

Entonces, ¿cómo aborda el tema de los viejos hábitos? John recomienda un enfoque lento y constante para cambiar la cultura de la empresa , creando conciencia sobre los beneficios estratégicos de una estrategia de API y animando a otros a crear soluciones a más largo plazo. Sin embargo, los beneficios no siempre son suficientes: María también reconoce los riesgos de no adoptar API, como una agilidad digital inferior o una pérdida de ventaja competitiva. Aclare estos problemas a las partes interesadas y puede ayudar a influir en ellos.

"La gente solo se moverá hacia lo desconocido si realmente cree que los riesgos de quedarse quietos son mayores que los riesgos de seguir adelante".

Lea también:  Consumo creciente de API internas en Danske Bank

2 - "No está en el presupuesto"

El costo es otra razón por la que las organizaciones pueden dudar en crear API. Aparte del costo de oportunidad de crear API, que analizaremos en un segundo, existen costos directos asociados con su mantenimiento . Incluso si lo está desarrollando usted mismo, debe tener en cuenta el costo de alojamiento, soporte y marketing. Y tan pronto como subcontrate un portal para desarrolladores o una puerta de enlace API, los costos pueden acumularse rápidamente.

Si el costo es una preocupación genuina, busque educar a las partes interesadas sobre los posibles ahorros de costos o las oportunidades de monetización de un programa API bien ejecutado. Esto es particularmente poderoso si puede proporcionar estimaciones concretas de cómo se pagarán las API; por ejemplo, puede encontrar que reemplazar las integraciones de socios existentes con API libera a los administradores de cuentas para trabajar en otros proyectos.

A largo plazo, sepa que escuchar repetidamente “no está en el presupuesto” puede ser un problema de prioridades desalineadas. Si este es el caso, el enfoque de María centrado en el riesgo para liderar el cambio puede ayudar a generar urgencia para las API.

Relacionado: 5 beneficios indirectos de construir API-First

3 - "No es un buen momento"

Como hemos establecido, existe un costo en dólares claro asociado con las API de alojamiento y sus activos de soporte. Dicho esto, un costo mucho más significativo es el costo de oportunidad de que los desarrolladores pasen meses creando API cuando podrían estar trabajando en otros proyectos. Especialmente si una organización actualmente obtiene valor de las integraciones de socios uno a uno, esto podría desanimar a las partes interesadas.

Sepa que esta es una buena razón para no querer dejar todo y seguir una estrategia de API. Sin embargo, no es una buena razón para deshacerse de las API por completo. Asumiendo que las partes interesadas ya reconocen su importancia, María sugiere comenzar con algo pequeño (sin dejar de pensar en grande). Un producto de API mínimo viable que admita solo unos pocos casos de uso aún puede demostrar mucho valor, sin requerir mucho compromiso. Luego, puede aprovechar el éxito con más apoyo de las partes interesadas. Si eso no funciona, otra estrategia es solicitar la aceptación para comenzar a trabajar en las API en una fecha futura específica, digamos, de 6 a 12 meses después.

En los últimos años, la economía web se ha transformado en una economía de plataforma. Se podría argumentar que ahora es el mejor momento para centrarse en las API. De lo contrario, las instituciones se enfrentarán a oportunidades comerciales perdidas y oportunidades de socios perdidas a medida que los competidores se conviertan en los primeros en el mercado.

Lea también: Cómo tratar su API como un producto

4 - "No es nuestro trabajo"

Este es otro argumento que puede haber escuchado al preguntar sobre las API. Es difícil de responder ya que la parte interesada no niega su valor; en cambio, están transfiriendo la responsabilidad a otra persona. Por supuesto, esto puede ser una excusa válida en ocasiones: si alguien más es responsable de la estrategia de integración (o la falta de ella), esta respuesta es natural. Pero, ¿qué pasa cuando esta excusa es solo eso, una excusa?

Primero, asegúrese de que las partes interesadas comprendan cuán amplios son los beneficios de las API . Explique cómo pueden aportar valor a las empresas en prácticamente cualquier industria , de diversas formas. Es posible que las partes interesadas no sepan que una infraestructura de API puede servir a los socios al tiempo que facilita el desarrollo interno. De hecho, debido a esto, la adopción de API debería ser un esfuerzo de colaboración en toda la organización. Si esto no es suficiente, siempre puede recurrir a la sugerencia de María para resaltar los riesgos de quedarse quieto, especialmente en lo que se refiere a su equipo.

5 - "Es demasiado arriesgado"

Definitivamente existen riesgos involucrados en la búsqueda de una estrategia de API, y las partes interesadas lo reconocen. Durante el desarrollo, existe el riesgo de que las cosas tarden más de lo esperado, lo que aumenta el costo de oportunidad e interrumpe los plazos de otros proyectos. Entonces, existe el riesgo de que nadie use sus API. Finalmente, y quizás lo peor de todo, existe el riesgo de que sus API conduzcan directamente a una brecha de seguridad.

Puede intentar equilibrar estos riesgos con los de no adoptar API, como se describió anteriormente. Quizás un enfoque más eficaz es satisfacer las preocupaciones de las partes interesadas individuales con planes para medidas de mitigación concretas. Por ejemplo, si las partes interesadas están particularmente preocupadas por la seguridad de la API , María sugeriría comenzar con una API solo para GET. Del mismo modo, si la adopción es una preocupación, optimizar para el éxito del desarrollador  y mejorar el marketing puede mejorar el compromiso.

6 - "¿No tenemos ya una API?"

Esta última refutación se origina en el hecho de que muchas grandes organizaciones ya tienen algún tipo de interfaz de integración heredada. Los viejos procesos punto a punto pueden ser suficientes a los ojos de las partes interesadas o, peor aún, pueden confundirse con las API. Después de todo, ¿no ofrecen la misma funcionalidad básica?

Para abordar este problema, asegúrese de que las partes interesadas vean los beneficios prácticos de las API sobre otros métodos de integración. En particular, las API son interfaces flexibles de uno a muchos, mientras que los métodos de integración tradicionales, como los basados ​​en ESB o ETL, se basan en componentes de un solo propósito. Esto significa que las API pueden servir a una multitud de clientes y casos de uso, con una relación calidad-precio mucho mayor.

Postamble

Si está impulsando la adopción de API en su organización, es probable que haya escuchado algunas de estas excusas. Con un poco de suerte, estos consejos proporcionados por María, John y nosotros le ayudarán a conseguir la aceptación de un programa API. Recuerde: se trata de resaltar los beneficios de adoptar API y los riesgos de no hacerlo ... ¡esas partes interesadas escépticas no sabrán qué los golpeó!

Publicar un comentario

0 Comentarios