Según un informe de IDC de 2021, el 75 % de las empresas encuestadas esperaban “transformarse digitalmente” en la presente década y esperaban que el 90 % de todas las aplicaciones nuevas presentaran una arquitectura de microservicios impulsada por API.1 También se señaló que, para Organizaciones centradas en API, hasta el 30% de los ingresos se generaron a través de canales digitales. Al mismo tiempo, estas empresas identificaron barreras clave para la adopción de API como “complejidad”, “seguridad” y “gobernanza”.

Finalmente, este fue uno de los hallazgos clave del resumen:

“Definir la arquitectura de aplicaciones correcta requiere una comprensión profunda de los desafíos relacionados con el gobierno, la gestión y la orquestación de estos componentes tecnológicos fundamentales”.

Un tendencia que se ha visto en los últimos años es una brecha cada vez mayor entre los que tienen API y los que no tienen API. Por ejemplo, ante la pregunta “¿Tiene su empresa una plataforma de gestión de API?” El 72 % de las empresas de medios y servicios respondieron “sí”, mientras que solo el 46 % de las empresas del sector manufacturero respondieron afirmativamente. Todo indica que las API seguirán impulsando el crecimiento empresarial en el futuro, y es imperativo que las empresas de todos segmentos de la economía se enfrentan al desafío de la transformación digital.

La buena noticia es que hay muchas empresas que gestionan con éxito sus programas de API. La noticia no tan buena es que su experiencia y conocimientos no se comparten fácilmente ni están disponibles de forma común. Hay varias razones para esto. La mayoría de las veces, las organizaciones a las que les está yendo bien en sus programas de administración de API simplemente están demasiado ocupadas para compartir sus experiencias con otros. En algunos casos, hemos hablado con empresas que tienen mucho cuidado con la cantidad de su experiencia en administración de API que comparten con el mundo exterior; están convencidos de que las habilidades API son una ventaja competitiva y tardan en hacer públicos sus hallazgos. Finalmente, incluso cuando las empresas comparten su experiencia en conferencias públicas y a través de artículos y publicaciones de blog, la información que comparten suele ser específica de la empresa y difícil de traducir a una amplia gama de programas API de las organizaciones.

Un desafío clave para identificar desde el principio es determinar qué quiere decir la gente cuando habla de API. Primero, el término API se puede aplicar solo a la interfaz (por ejemplo, una URL de solicitud HTTP y una respuesta JSON). También puede hacer referencia al código y los elementos de implementación necesarios para poner en producción un servicio accesible (p. ej., la API customerOnBoarding). Por último, a veces usamos API para referirnos a una única instancia de una API en ejecución (por ejemplo, la API de integración del cliente que se ejecuta en la nube de AWS frente a la API de integración del cliente que se ejecuta en la nube de Azure).

Otro desafío importante en la gestión de las API es la diferencia entre el trabajo de diseño, creación y lanzamiento de una sola API y el soporte y la gestión de muchas API, lo que llamamos un landscape de APIs. .

El otro extremo de ese espectro es el trabajo de administrar el landscape de APIs. Este es  la colección de API de todos los dominios comerciales, que se ejecutan en todas las plataformas, administradas por todos los equipos de API de su empresa. Hay varios aspectos en los desafíos de este panorama, que incluyen cómo la escala y el alcance cambian la forma en que se diseñan e implementan las API, y cómo los ecosistemas grandes pueden introducir volatilidad y vulnerabilidad adicionales solo por su tamaño.

Gobierno de APIs

El modelo de gobernanza cambiará a medida que crezca el ecosistema de APIs de una compañía. Es así como se identifica que aparecen nuevos desafíos y los viejos métodos no son tan efectivos como lo eran en el pasado. De hecho, especialmente a nivel empresarial, apegarse a los modelos de gobierno antiguos puede retrasar o incluso detener el éxito de sus API.

Al igual que en cualquier área de liderazgo, cuando el alcance y la escala son limitados, un enfoque basado en brindar orientación directa puede ser el más efectivo. Esto suele ser cierto no solo para equipos pequeños, sino también para equipos nuevos. Cuando no hay mucha experiencia operativa, la forma más rápida de lograr el éxito es brindar esa experiencia en forma de orientación detallada y/o documentos de proceso. Por ejemplo, encontramos que el control temprano del programa API a menudo toma la forma de documentos de proceso de varias páginas que explican tareas específicas: cómo diseñar las URL para una API, o qué nombres son válidos para las URL, o dónde debe aparecer el número de versión en un HTTP. encabezamiento. Brindar pautas claras con pocas opciones dificulta que los desarrolladores se desvíen de la forma aprobada de implementar sus API.

Pero nuevamente, a medida que su programa de APIs empresarial crece, a medida que agrega más equipos y admite más dominios de negocio, el tamaño y el alcance de la comunidad comienzan a dificultar el mantenimiento de un único documento de orientación que se aplica a todos los equipos. Y si bien es posible “contratar” el trabajo de escribir y mantener documentos de proceso detallados para toda la empresa, generalmente no es una buena idea de todos modos, como mencionamos en “Tecnología”, la variedad de tecnología se convierte en una fortaleza en un ecosistema grande. , e intentar controlarlo en el nivel de gobierno empresarial puede retrasar el progreso de su programa.

Es por eso que a medida que su Landscape de API se expande, sus documentos de gobierno deben cambiar de tono para pasar de ofrecer instrucciones de proceso directas a proporcionar principios generales. Por ejemplo, en lugar de escribir detalles sobre lo que constituye una URL válida para su empresa, es mejor señalar a los desarrolladores las pautas del Grupo de Trabajo de Ingeniería de Internet sobre diseño y propiedad de URI (RFC 7320) y brindar orientación general sobre cómo aplicar esta información pública. estándar dentro de su organización. O Estos tipos de documentos brindan muchas opciones y razones para usar un patrón de interfaz de usuario sobre otro. Ofrecen orientación a los desarrolladores y diseñadores sobre por qué y cuándo usar algo en lugar de simplemente establecer requisitos para que los sigan.

Finalmente, para las grandes organizaciones, y especialmente las empresas que operan en múltiples ubicaciones y zonas horarias, la gobernanza debe pasar de distribuir principios a recopilar consejos. Esto esencialmente invierte el modelo típico de gobierno central. En lugar de decirles a los equipos qué hacer, la función principal del comité de gobierno central es recopilar información de la experiencia del campo, encontrar correlaciones y hacer eco de la guía que refleja las “mejores prácticas” dentro de la organización en general.

Por lo tanto, a medida que crece su landscape de API, su modelo de gobierno de API debe pasar de brindar asesoramiento directo a presentar principios generales para recopilar y compartir prácticas de equipos experimentados dentro de su empresa.