API Strategy – La guía definitiva (Parte I)

Las APIs se han convertido no solamente en el principal mecanismo de integración, sino también en un nuevo canal para las compañías. Es por ello importante arrancar las iniciativas de Enterprise APIs siguiendo una estrategia. En toda API Strategy es fundamental definir cuales son los roles de la organización que van a intervenir, elegir una plataforma de integración que se adapte a sus necesidades, definir un conjunto de buenas prácticas, construir un marketplace, definir las políticas de seguridad y la estrategia de monitorización.

Esta guía definitiva de API Strategy que presentamos a continuación consta de dos partes. En esta primera parte veremos temas tan fundamentales como la importancia de una API Strategy, roles y responsabilidades, elegir una plataforma de API, gobierno y buenas prácticas.

¿Por qué es importante tener una API Strategy?

Hay varios motivos por el que las empresas están invirtiendo recursos en arrancar un API Program:

• Construir un nuevo canal de venta. Al igual que el canal telefónico o el canal web, las APIs constituyen un nuevo canal. Así, por ejemplo, un banco puede exponer una API para contratar depósitos, de tal manera que esta se pueda utilizar como un paso más en el proceso de venta de una tienda online, originando ingresos a través del canal.
• Mejorar capacidades B2B. Tradicionalmente, las empresas se han comunicado telemáticamente con sus partners utilizando múltiples estrategias: compartiendo ficheros XML o planos vía FTP, intercambiando mensajes EDI usando el protocolo AS2, etc. Las APIs simplifican el enrolment de estos B2B partners, así como el desarrollo de aplicaciones de intercambio de información, ya que se basan en estándares y protocolos como HTTP o JSON que están ampliamente soportados por todos los lenguajes de programación.
• Construir un conjunto de funcionalidades reutilizables que se puedan utilizar para construir nuevas aplicaciones móviles, integrar aplicaciones en la nube, etc.
• Fomentar la innovación y los proyectos de transformación digital. En particular, cuando existe un conjunto de APIs totalmente públicas que se dan a conocer a la comunidad, se posibilita que desarrolladores independientes utilicen dichas APIs para construir nuevas aplicaciones innovadoras.

Definir roles y responsabilidades

El primer paso en toda API Strategy pasa por involucrar a los diferentes departamentos de la compañía y darles un papel en el ciclo de vida de las APIs.

Un error común es asumir que las APIs son tan solo artefactos técnicos – como podría ser un fichero de configuración o una tabla en base de datos – de tal manera que solo el área de Sistemas conoce su existencia y se involucra en su definición. Este acercamiento acaba generando una capa de APIs técnicas que no tiene ninguna visibilidad para las áreas de negocio, desaprovechando la oportunidad para poder crear nuevos productos digitales basados en esas APIs.

Cuando por el contrario las áreas de negocio se involucran en el API Program desde el primer momento, estas tienen la posibilidad de estudiar lo que están haciendo otras compañías – del mismo sector o de otros – para a partir de ahí tomar un peso protagonista en la decisión de cuál debe ser el roadmap, cuáles deben ser los primeros productos digitales a construir y cuáles deben ser los integrantes del ecosistema que se construya alrededor de las APIs.

Otra decisión que se toma en este ámbito es relativa a cuál debe ser el ciclo de vida de las APIs y cuál debe ser la manera en la que estas se construyan:

• En algunas organizaciones, se decide que cualquier equipo de desarrollo puede tener capacidad para definir y publicar APIs. Esta configuración tiene la ventaja de que el proceso de creación de APIs es más dinámico, pero puede ocasionar que las APIs tengan un aspecto menos uniforme o que se dupliquen esfuerzos.
• En otras organizaciones, se decide crear un grupo especializado – conocido comúnmente como Centro de Excelencia en APIs – que centraliza todos los esfuerzos relacionados en el gobierno de las APIs. Esta configuración aporta un mejor gobierno, pero en ocasiones puede suponer un cuello de botella.

Dentro de los principales roles que se definen en una API Strategy destacan dos:

• El API Product Owner, que normalmente será un perfil que entienda perfectamente las capacidades de las APIs como nuevo canal y que también tenga un conocimiento del producto a nivel de negocio.
• El Developer Advocate, que se constituye como la voz de la comunidad de consumidores dentro de la organización y que se ocupa de mantener y dinamizar el portal de APIs y de hacer crecer la comunidad de partners.

Una vez definidos los roles, el siguiente paso es definir cuáles deben ser los objetivos del API Program. Uno de los objetivos puede ser la disponibilidad de APIs públicas, pero también puede serlo el de crear APIs orientadas a un conjunto cerrado de partners.

Elegir una plataforma de APIs

Una vez que se han definido los objetivos del API Program, el siguiente paso es decidir cuál debe ser la plataforma de integración a utilizar para exponer APIs.

Cualquier plataforma de APIs debe disponer como mínimo de los siguientes elementos:

• Una herramienta que permita gobernar el ciclo de vida de las APIs, desde su definición hasta su publicación, pasando por la gestión de los partners que están subscritos.
• Un API Gateway que se ocupe de garantizar que se cumplen las políticas de seguridad. Este API Gateway habitualmente ofrece facilidades para ser desplegado tanto on-premises como en cualquier nube, de tal manera que el Gateway y sus políticas se gobiernan desde un punto central, pero corre los más cerca posible de los datos, facilitando escenarios de integración híbrida.
• Un API Portal o Marketplace donde está el escaparate de los productos digitales pero donde también se gestiona la comunidad de partners.

Adicionalmente, las plataformas de integración ofrecen capacidades extendidas que complementan el API Gateway:

• Capacidades para construir orquestaciones e integraciones con diversos sistemas backend y legacy.
• Capacidades para construir servicios asíncronos.
• Capacidades para construir integraciones B2B basadas en EDI o MFT.
• Capacidades para realizar integraciones a nivel de datos.

Otros aspectos importantes que se deben estudiar a la hora de evaluar el vendor idóneo, es el soporte de nuevos estándares como puede ser GraphQL, websockets, APIs asíncronas, etc. Es también aconsejable analizar las opciones de despliegue que ofrece la plataforma, siendo un aspecto muy importante la capacidad de ser desplegadas como contenedores en un PaaS.

Gobierno y buenas prácticas

Una vez que la plataforma de integración está operativa, es preciso definir una serie de estándares y buenas prácticas:

• Buenas prácticas a la hora de diseñar APIs siguiendo el estándar RESTful.
• Nomenclatura, tanto de las URLs como de los atributos y parámetros de entrada y salida.
• Patrones y estándares, por ejemplo para tratar archivos grandes, polimorfismo, asincronía, negociación de contenidos, etc.
• Versionado de APIs. Técnicas para desarrollar cambios que sean retrocompatibles.

El paradigma API First se basa en que el primer paso en todo proyecto de desarrollo debe ser definir su API y solamente una vez que esta ya está definida, pasar a construir el resto de artefactos del proyecto, como puede ser por ejemplo la interfaz de usuario.

En el caso de las grandes compañías multinacionales, es común que cada filial tenga su propio API Program e incluso su propia plataforma de integración apoyada en vendors diferentes. Esto acaba ocasionando que sea complicado ofrecer un único Portal de APIs con un conjunto de APIs comunes, a menos que desde un área corporativa se ponga en marcha un proyecto de unificación y de definición de estándares. Este tipo de proyectos suele tener como objetivo exponer un único Portal de APIs unificado, que sea consumible por grandes partners globales y que una vez que se ejecuten llamadas hacia estas APIs comunes, estas sean desviadas o enrutadas hacia las implementaciones locales en cada filial.

En la segunda parte de esta guía definitiva de API Strategy, podrás seguir profundizando en materias como los marketplaces y ecosistemas de partners, la herramienta de sandbox, seguridad y anti hacking, capa de orquestación, monitorización y monetización, integración y despliegue continuo.

No te pierdas… API Strategy – La guía definitiva (Parte II)