La colaboración entre Autentia y Orange Bank empezó al mismo tiempo que el propio desarrollo del banco a todos los niveles.

Y yo tuve la suerte de ser el primer “autentio” en entrar al proyecto. Bueno, ahora digo “suerte” pero cuando me comunicaron que ese podría ser mi próximo destino, pensé “qué gran responsabilidad” y me sentí bastante agobiado.

Esto no significa que no me gusten los retos, al contrario, me encanta enfrentarme a nuevas situaciones fuera de mi zona de confort, pero ¡menudo reto!

Además, tenía dos buenos motivos para sentirme seguro.

El primero, la confianza puesta en mí por parte de la dirección de Autentia. Por muchas dudas que tuviera sobre mis capacidades y aptitudes, si ellos me ofrecían estar al frente de este proyecto era porque sabían que podía hacerlo bien.

El segundo, saber que no estaba solo, es decir, que yo simplemente era el representante técnico de Autentia en Orange Bank y que detrás de mí estaban todos mis compañeros, verdaderos cracks con enormes conocimientos y experiencia.

Los comienzos

El alcance inicial de la colaboración fue definir la estrategia tecnológica del banco. Así que, como uno más entre las poquísimas personas que en aquel momento formaban parte de Orange Bank, participé en las presentaciones y selecciones de proveedores y colaboradores.

Fue una experiencia alucinante. En un ambiente de absoluta confianza, cercanía y buen rollo, avanzamos a un ritmo frenético.

Llegado el momento de decidir si el middleware se compraba o se desarrollaba en casa, nos encargaron proponer un modelo de desarrollo y una arquitectura de sistemas. 

Y aquí, una empresa como Autentia aporta un valor diferencial. Por un lado, porque el punto de partida fue comprender e interiorizar las necesidades estratégicas del negocio, en particular la necesidad de salir a producción en poco más de un año con un buen producto. Y por otro, porque la propuesta de arquitectura se fraguó en una reunión en la que compañeros de otros proyectos aportaron su experiencia, conocimientos e ideas.

Las conclusiones de esa reunión y otras conversaciones posteriores fueron:

1. Reducir la barrera de entrada a nuevos desarrolladores optando por el stack tecnológico más extendido, o sea, Java.
2. Dedicar el mínimo tiempo a frameworks y arquitectura aprovechando Spring Boot, enriqueciéndolo con los starters justos.
3. Promover buenas prácticas y cultura de calidad y testing a todos los niveles, aplicando TDD y ATDD.
4. Minimizar bloqueos y dependencias entre equipos con un enfoque de microservicios, “API first”, Consumer-Driven Contract Testing y comunicación asíncrona basada en eventos.
5. Fomentar la autonomía de los equipos a través de “trunk based development”, DevOps con CI/CD automatizadas desde la propia infraestructura (cloud, por supuesto).
6. Imágenes Docker como unidad de despliegue en un runtime potente, flexible y seguro basado en Kubernetes. Esto también facilitó las pruebas de aceptación de caja negra.

Más de 2 años después de aquello, ha quedado de sobra demostrado que entre todos tomamos las decisiones correctas.

La prueba de concepto

Una vez aprobada la propuesta por parte de Orange Bank Francia, el equipo técnico de Delivery comenzó a crecer, no solo con compañeros de Autentia, sino de otros colaboradores.

Pero aunque el origen era indiferente, todos éramos un equipo y estábamos ahí para demostrar que se podía montar un banco desde cero, en poco tiempo y con buena calidad.

Esta demostración consistió en una prueba de concepto “end to end” de algunas funciones básicas de una cuenta corriente e integrando ya algunos componentes de terceros.

En el front, se aprovechó la prueba para valorar si era mejor optar por aplicaciones nativas o híbridas, resultando ganador el desarrollo nativo.

La prueba superó las expectativas y después de las vacaciones de verano, volvimos cargados de energía para afrontar el desarrollo del verdadero producto.

Desarrollo en paralelo

Este proyecto es un caso de éxito claro de qué ocurre cuando la estrategia de negocio está perfectamente alineada con el desarrollo de producto software. Negocio confió plenamente en la manera en que se debía desarrollar el software y nosotros entendimos bien sus necesidades. Desde el principio hubo un gran entendimiento mutuo.

Aprovechando la Ley de Conway, la organización se estructuró en torno a las áreas del producto tal y como el cliente esperaba disfrutarlas. Y los squads de desarrollo eran parte de esas estructuras organizativas.

Por otro lado, aunque un objetivo primordial era la autonomía de los equipos para avanzar sin bloqueos, la colaboración fue fundamental, estableciendo poco a poco mecanismos ágiles para negociar los contratos de APIs, tanto REST como de productores/consumidores de eventos.

Desde infraestructura, se fomentaron las prácticas DevOps con una plataforma self-service muy automatizada con pipelines y GitOps.

Todo esto nos llevó a conseguir un impresionante ritmo en la entrega de software y a poder cumplir los plazos, sprint tras sprint y PI tras PI.

La transición de Autentia

Echando la vista atrás, ahora soy más consciente de cómo progresó nuestra dedicación en este proyecto.

Al principio fue casi todo arquitectura y su aplicación a la prueba de concepto.

Entonces el equipo de Autentia empezó a dispersarse por todos los equipos del banco, ejerciendo de líderes técnicos, mentores y promotores de los principios y valores de Orange Bank. Así, de manera muy natural, fuimos pivotando el foco desde el chapter de arquitectura a los squads encargados de las distintas funcionalidades verticales del producto, hasta que ya apenas fue necesario dedicar esfuerzo a cuestiones transversales.

Como apunte personal, estoy totalmente convencido de que la labor de un equipo de arquitectura debe ser precisamente ésta. Es decir, desarrollar funcionalidades dentro de los equipos, quizás las más complicadas desde el punto de vista técnico, y sólo dedicar tiempo a la arquitectura “pura” cuando realmente sea necesario, por ejemplo, por algo que bloquee a uno o varios equipos. Esto no significaba eliminar el chapter de arquitectura, al contrario, se mantenían reuniones periódicas para poner en común ideas, problemas y posibles soluciones y sobre todo aprovechar sinergias entre los equipos.

Salida a producción y futuro

Tras dos fases de pruebas para miembros de Orange Bank y familiares y amigos, la salida a producción fue muy bien, tal y como se esperaba.

El plan de llevar pocas funcionalidades bien diseñadas e implementadas tuvo éxito y nos dio tranquilidad. Aunque eso no significa que no hubiera problemas. Y, además, siempre hay margen para la mejora.

En particular, recuerdo dos aspectos transversales, más allá de otras cuestiones funcionales:

El primero, la complejidad de controlar los errores y asegurar la consistencia de todo el dominio en una arquitectura orientada a eventos. Todo no se puede prever, y en el mundo real ocurren fallos; la infraestructura puede fallar o un flujo interrumpirse en algún punto y acabar en error. Estas situaciones nos obligaron a ejecutar acciones de compensación, a veces siendo necesario volver a consumir un topic completo.

El segundo, que se podrían mejorar los tiempos de entrega si todos los equipos hicieran despliegue continuo en producción (algunos ya lo hacen) en vez de coordinar los despliegues a través de “release trains”. 

De todas formas, lo importante es que gracias a una política “trunk based development”, todos los artefactos siempre van a estar listos para ser promocionados a producción en cualquier momento, ya que no es admisible subir código roto que no pase los tests o las métricas de Sonar.

A parte de esto, las necesidades de los usuarios no paran de evolucionar, así que el software también debe hacerlo al mismo ritmo. Por ejemplo, poniendo el foco en asegurar la escalabilidad del sistema ante un aumento de clientes y ampliando las operativas bancarias y productos disponibles.

Conclusiones

A nivel de proyecto, repito lo que he escrito más arriba por su importancia: La probabilidad de éxito aumenta considerablemente cuando la estrategia de negocio y la estructura organizativa están bien alineadas con el producto y su desarrollo.

Si a eso añades un capital humano excelente, con buenos principios y valores, confianza y seguridad psicológica, gran espíritu de colaboración y con objetivos claros y compartidos, entonces es casi seguro que las cosas vayan bien.

A nivel personal, con este proyecto he podido aprender y aplicar muchísimas ideas, adquiriendo una experiencia única que traté de compartir a través de la charla “Una experiencia con microservicios en banca”.

Me siento realmente un privilegiado por haber podido formar parte de este gran proyecto. Dejo en Orange Bank grandes compañeros y amigos. Ojalá vuelva a coincidir con ellos en el futuro.