Header Ads Widget

Ticker

6/recent/ticker-posts

Estudio de caso: Consumo creciente de API internas en Danske Bank



Una desafortunada verdad de las API es que rara vez se venden por sí mismas. Incluso internamente, muchas organizaciones se encuentran con una adopción deficiente cuando adoptan un enfoque de configurar y olvidar para implementar nuevas API. La buena noticia, sin embargo, es que hay muchas formas de mitigar esto, asegurando un consumo constante de API entre los desarrolladores internos y externos.

En este artículo, veremos tres razones por las que un equipo de desarrollo de API en Danske Bank, el banco más grande de Dinamarca, vio una mala adopción de sus API internas y los pasos que tomaron para establecer el crecimiento en un gradiente mucho más pronunciado.

Basamos esta publicación en una charla impartida por John Madsen , propietario de producto API para información del cliente en Danske Bank , en la cumbre de plataforma 2019 en Estocolmo. Mira la charla completa aquí:

El camino hacia las API

Antes de adoptar las API, la arquitectura técnica de Danske Bank encajaba en gran medida con el estereotipo de cualquier banco: monolítica y de movimiento lento. Con algunos sistemas que tenían más de cincuenta años, y en continuo crecimiento, era difícil mejorar, arreglar o construir algo. Sin mencionar que muchos de los sistemas se construyeron con tecnologías obsoletas. John bromea diciendo que muchos problemas solo pueden ser resueltos por "esa persona específica".

Naturalmente, esta arquitectura de TI pesada resultó en una velocidad de cambio reducida. Fácilmente podría llevar medio año, un año o incluso más desarrollar nuevos productos y servicios. Como resultado, la organización decidió que ya era suficiente, y era hora de desenredar el lío.

John explica brevemente el proceso de cómo Danske Bank logró agrupar sus sistemas técnicos en subdominios aptos para API. Para empezar, dividieron su pila existente en tres capas: una capa fundamental (que consiste principalmente en un sistema de registros), una capa de proceso o función (que proporciona datos significativos a los consumidores) y una capa de experiencia (responsable de los puntos de contacto individuales del cliente, tales como: como aplicaciones).

Luego, en la capa base, el banco desglosó su sistema de registros en subdominios orientados a objetos, por ejemplo, clientes. Cada uno de estos objetos se convirtió en la base de una API (o conjunto de API).

Rendimiento de configurar y olvidar

Después de abstraerse con éxito de la complejidad de su mainframe, Danske Bank pudo crear un amplio conjunto de API internas intuitivas. Habiendo creado estas API, esperaban que el consumo creciera rápidamente sin mucha promoción.

Desafortunadamente, el equipo se encontró con un gráfico de consumo lento y constante, y no con la curva del palo de hockey que habían anticipado. John imagina que este es el caso de muchos bancos e instituciones financieras que adoptaron el mismo enfoque. Pero, ¿qué hizo mal Danske Bank para cumplir con este consumo interno de API por debajo de la media?

Identificar los contratiempos ... ¡y abordarlos!

En retrospectiva, John identifica tres contratiempos particulares en el consumo de sus API internas: viejos hábitos, fricción y falta de marketing. Explica cada uno de estos problemas en profundidad, y también analiza algunas de las soluciones utilizadas para abordarlos.

Viejos hábitos

A pesar de un conjunto de API REST nuevas y elegantes, el equipo descubrió que los desarrolladores no estaban entusiasmados con el cambio. Esto se debe a que, en otras partes de la organización, grupos separados continuaban apoyando formas alternativas de integración. El punto de vista predominante fue: si todavía puedo usar esta integración punto a punto, ¿por qué cambiar?

Las correcciones

Una solución definitiva a esta renuencia al cambio fue simplemente poner fecha límite a los métodos de integración más antiguos. Al anunciar que dejarían de admitir una integración punto a punto específica en tres o seis meses, John descubrió que los desarrolladores reaccionaron rápidamente al adoptar las nuevas API. Por supuesto, este enfoque severo requiere la participación de los gerentes. Al hacerlo, Jon señala que los plazos siempre se pueden utilizar como moneda de cambio.

Quizás una solución más complaciente fue que el equipo también impulsó cambios en la cultura de la empresa. Al alentar a otros a crear soluciones a más largo plazo con las API, y defender la importancia de hacerlo con los gerentes, el equipo con frecuencia pudo empujar a los desarrolladores hacia un rumbo más estratégico.

Fricción

Los desarrolladores que tenía quieren adoptar las nuevas API se encontraron con otro problema: la fricción en el descubrimiento y el consumo de las API. De hecho, el equipo ofreció una herramienta de descubrimiento de API, pero John dice que simplemente se introdujeron demasiadas "cosas", lo que provocó una frustración inicial.

Una causa posterior de fricción fueron las fichas de seguridad; los desarrolladores no estaban seguros de cómo crearlos. Este malentendido hizo que las nuevas API REST fueran difíciles de consumir desde plataformas independientes.

Las correcciones

La solución natural a esta fricción fue mejorar el recorrido del desarrollador. Al mejorar las áreas anteriores para facilitar el proceso de incorporación, era más probable que los desarrolladores buscaran soluciones basadas en API. Un área con la que Danske Bank no tuvo problemas fue la documentación específica de API, pero otras podrían hacerlo.

Márketing

No debería sorprender que el equipo, un grupo de técnicos "en el calabozo", haya pasado por alto por completo la importancia del marketing. Luchando contra una agenda apretada, casi no hicieron promoción para sus nuevas API. Naturalmente, esto significó que menos desarrolladores sabían que existían las API en primer lugar.

Las correcciones

La solución para esta falta de marketing fue simple: el equipo tuvo que salir y vender sus nuevas API. Esto significó tocar muchas puertas. Se pusieron en contacto con directores de desarrollo internos, ingenieros, arquitectos, CIO y gente de negocios para compartir sus últimos desarrollos. John descubrió que con cada reunión, la iniciativa ganaba impulso.

Los resultados

Entonces, ¿cuáles fueron los resultados de las muchas maniobras de Danske Bank para mejorar el consumo de API? Afortunadamente, el crecimiento se aceleró rápidamente. Si bien no era el crecimiento exponencial que John había esperado, podía sentir que las nuevas API estaban ganando terreno en la organización. Los signos reveladores de este nuevo crecimiento, recuerda, fueron cuando los desarrolladores comenzaron a llamarlo, diciendo cosas como "Escuché de él / ella que tiene algunas API nuevas", o cuando la gente de negocios comenzó a invitarlo a presentar las nuevas API a otras.

Resumen

Incluso las mejores API pueden sufrir una adopción lenta. En esta publicación, analizamos tres razones por las que las API internas de Danske Bank tardaron en ganar tracción. Según John Madsen , un propietario de producto que luchó en esta batalla en primera línea, los viejos hábitos, la fricción de incorporación y la falta de promoción son las principales causas del crecimiento deficiente de API. Con suerte, las soluciones que aquí se presentan deberían ayudar a minimizar estos problemas, asegurando una adopción segura y constante.

Publicar un comentario

0 Comentarios