Header Ads Widget

Ticker

6/recent/ticker-posts

De API Doing a API Thinking en un banco importante


 En cualquier organización importante, es difícil sentir que puede marcar la diferencia solo con sus habilidades tecnológicas. No sorprende que la ingeniera de software Flavia Sequeira sintiera exactamente eso cuando se unió a ING, la firma bancaria multinacional con más de 50.000 empleados, en 2013.

Verá, crear un producto de TI impactante puede llevar mucho tiempo y esfuerzo, y es difícil para la gerencia entusiasmarse con eso cuando no ofrece una propuesta de valor inmediata. ¿Quién necesita una API cuando podemos arreglar el tiempo de inactividad del servidor o arreglar la interfaz de usuario para las vacaciones del próximo mes?

Ese fue el caso de las API cuando Flavia se unió a ING. Los empresarios sabían que querían un enfoque más abierto a la tecnología, uno que potencialmente pudiera cambiar la faz de la banca del siglo XXI, pero no era obvio por dónde empezar.

Sorprendentemente, la creación de una API no fue una solución obvia para eso, y menos cuando el equipo de TI ya había creado un servicio web.

Ha sido el viaje de Flavia en los últimos cuatro años para educar a sus compañeros de trabajo sobre los beneficios de una API de pensar , en lugar de sólo una API haciendo , mentalidad, y todo comienza con un caso de la semántica.

Vea a Flavia Sequeira presente en la Cumbre de Plataformas Nordic APIs 2017:

API versus servicios web: ¿cuál es la diferencia?

Flavia habla de una de las primeras sesiones de la comunidad API en ING, donde una abrumadora negatividad hacia las API llenó la sala. Los desarrolladores experimentados simplemente no podían ver qué tenían para ofrecer las API que su servicio web no.

El consenso común es que los servicios web ofrecen un rango de funcionalidad más limitado que las API, entregando datos particulares en un formato estandarizado. Esto se opone a ofrecer una suite de desarrollo integral para construir sobre un producto de TI existente. Flavia tenía (y todavía tiene) su propia opinión sobre el asunto:

“Las API se construyen” de afuera hacia adentro ”, anunció en la reunión, seguida de un largo silencio.

Cuando se le pidió que ampliara lo que quería decir, Flavia explicó que las API deben construirse desde la perspectiva del cliente, según las necesidades del cliente , mientras que los servicios web se construyen desde la perspectiva de la organización, ofreciendo lo que ellos perciben como importante.

Esto significa que, mientras que los servicios web pueden ofrecer un solo servicio o un conjunto de servicios para que los clientes lo utilicen, las API de cara al público permiten mucha más interactividad con su producto, como el seguimiento de los viajes de los clientes.

API Doing vs API Thinking

La anécdota anterior deja en claro que Flavia se unió a ING con una mentalidad completamente diferente hacia las API. No estaba tan interesada en hacer API como pensaba en API , y ese era un enfoque completamente nuevo.

Ella no se preguntó:

  •  ¿Qué datos y funcionalidades creemos que son útiles para los usuarios?
  • ¿Cómo podemos proporcionarles esos datos y esa funcionalidad? (En otras palabras, ¿cómo construimos esta API?)

En cambio, se preguntó a sí misma:

  • ¿Cómo quieren nuestros usuarios interactuar con nuestros servicios y qué quieren construir?
  • ¿Cómo podemos facilitarles lo más posible?
  • ¿Cómo nos ayudará eso a comprender y atender mejor las necesidades de nuestros clientes?

Por supuesto, ese primer conjunto de preguntas, la API que hace preguntas, es tan importante como el segundo conjunto de preguntas. De hecho, son las preguntas más prácticas que debe hacer un desarrollador.

Sin embargo, es el segundo conjunto de preguntas, las preguntas de pensamiento de API, lo que realmente justifica que una organización esté construyendo una API. Es más, resuelven el dilema inicial de convencer a la administración de lo que ofrecen las API.

Lea también: Introducción a las API para los no iniciados

API y viajes de clientes

Continúa la anécdota de Flavia, paralelamente a lo que acabamos de decir. Ella recuerda cómo un empleado senior le pidió que ampliara sus pensamientos sobre los viajes de los clientes , probablemente preguntándose por qué un ingeniero de software estaría rastreando la experiencia de un cliente con ING de principio a fin.

La verdad es que los productos de TI bien diseñados están estrechamente vinculados a la conciencia de los comportamientos, requisitos y deseos del cliente. Esto último no solo ayuda a crear productos que le encantarán al usuario, sino que los productos que le encantan al usuario ayudarán a desarrollar los comportamientos, requisitos y deseos del cliente. Esto ocurre fomentando el pensamiento abierto en las etapas de desarrollo y proporcionando datos empíricos en las etapas operativas.

Esta es la razón por la que los viajes del cliente del departamento comercial de ING ayudan a crear mejores API y por qué mejores API ayudan al departamento comercial a crear viajes del cliente más completos y efectivos .

Las API comparten esa misma relación simbiótica con otras herramientas comerciales, como los planos de servicio y las prácticas comerciales, como el pensamiento de diseño. Estos allanan el camino para una API más funcional y completa, mientras que la API ayuda a visualizar y facilitar nuevas oportunidades.

Además, las API pueden ser una solución para desacoplar los extremos frontal y posterior , lo que permite que el producto final se vincule estrechamente con su funcionamiento interno, sin que los dos dependan completamente entre sí.

Este es el pensamiento de API . Es comprender lo que las API pueden hacer por la organización, desde una perspectiva holística , y no solo construir API sin sentido porque están de moda.

Relacionado: Desarrollo del libro electrónico API Mindset

Por qué API Doing es igualmente importante

Cuando se realiza un seguimiento de este tipo de pensamiento de alto nivel, es fácil olvidar el verdadero valor que pueden proporcionar las API en la banca de hoy en día - y eso es mucho en el hacer .

Vea, a diferencia de las herramientas comerciales mencionadas anteriormente, las API ofrecen tanto al usuario como al propio banco. El uso de API en la banca, que es parte de un movimiento mayor llamado banca abierta , permite a los servicios FinTech aprovechar la enorme base de información y la variada funcionalidad que los bancos ya tienen.

Piénselo: hay miles (si no millones) de aplicaciones de terceros y de primera parte integradas en nuestros teléfonos móviles, plataformas de redes sociales e incluso casas. Sin embargo, apenas existe un equivalente para los servicios bancarios actuales.

Imagínese tener una tienda de aplicaciones para su cuenta bancaria. Puede elegir entre miles de servicios, creados con el poder de pensamiento colectivo de desarrolladores externos, grandes y pequeños, que resolverían una multitud de problemas y cambiarían la banca para siempre.

Las posibilidades para esto son infinitas: recopile todas sus cuentas en un solo lugar, envíe efectivo a través de las redes sociales, administre sus patrones de gasto, verifique transacciones pasadas, etc., y así sucesivamente.

Con la forma en que están las cosas hoy, no es que no se pueda hacer, sino más bien que no es práctico. Por supuesto, cualquier servicio financiero, incluidos los bancos, debe estar bien protegido, con la información guardada en sistemas internos. Esta es la razón por la que el modelo existente (y muy limitado) de brindar a los servicios FinTech acceso directo a su cuenta (conocido como screen scraping ) simplemente no puede continuar. El servicio de administración financiera Mint realiza el rastreo de pantalla con regularidad, obteniendo acceso directo a sus cuentas bancarias, pero se siente lo suficientemente seguro sabiendo que su empresa matriz, Intuit, ya tiene millones de números de seguridad social.

Sin embargo, requerir información de inicio de sesión del usuario es una barrera de entrada significativa para los desarrolladores de FinTech más pequeños. Es posible que estas aplicaciones solo necesiten un alcance limitado de datos para operar, como sus fechas de gasto o ubicaciones en las que se ha utilizado su tarjeta de crédito.

Las API son una solución obvia para esto, permitiendo que los servicios de terceros interactúen con los bancos, extrayendo solo la información necesaria y realizando solo los servicios necesarios. Con los protocolos de delegación y autenticación estandarizados ampliamente establecidos para las API, no solo sería más seguro, sino que sería más efectivo .

Los cambios en la regulación, como con PSD2 en la Unión Europea , ya están presionando y preparándose para este cambio. Sin embargo, en última instancia, depende de los bancos abrirse al mundo de una manera que sea utilizable.

Lea también: Cómo PSD2 está creando efectos ondulantes para la banca abierta

De API Doing a API Thinking

Cuando Flavia se unió a ING, no solo les faltaba la ejecución de API, o "hacer API", sino que también les faltaba comprensión de API o "pensamiento de API". Esto dificultaba la ejecución de una estrategia de plataforma definida.

Ella resolvió esto animando a otros a mirar las API de manera integral, para comprender lo que aportan a una organización y sus clientes o socios, y para emplear esa misma información para luego construir mejores productos de TI.

A lo largo del viaje de Flavia, la descripción de su carrera ha cambiado de "ingeniera de software" a "pensadora de API". Ella no solo construye productos de TI en ING; en cambio, educa a otros desarrolladores sobre cómo esos productos, especialmente las API, pueden diseñarse de acuerdo con los valores de ING y las experiencias de sus clientes, y cómo eso a su vez les permitirá crear una mejor experiencia general para el cliente.

En última instancia, las API no se crean solo por hacer o pensar , deberían ser una combinación de los dos. A pesar de que Flavia es una pensadora de API, también tiene que haber varios hacedores de API en ING.

Publicar un comentario

0 Comentarios