Pasar de desarrollar productos a evolucionar productos.
Es bien sabido que los sistemas legados son un dolor de cabeza en las diferentes industrias y uno de los sectores que mas cuenta con entidades que tienen sistemas legados es el bancario, así como las empresas asociadas a la industria financiera, mas aun, la constante necesidad de implementar nuevas tecnologías aumenta la brecha entre las soluciones actuales construidas con las tendencias digitales y las construidas con tecnologías legadas que soportan a las primeras, aumentando la complejidad en el proceso de mantener dichas soluciones.
Y es que el mantener soluciones hace parte de un gran porcentaje del presupuesto de inversión, ya en en el 2015 un informe de Celent lo evidenciaba.
Sobre dicho informe recomiendo leer es siguiente articulo (Banks’ ageing IT systems buckle under strain) del Financial Times , el cual presagiaba la necesidad de realizar transformaciones en las soluciones tecnológicas del sector financiero.
Es por lo anterior que los bancos han modificado sus modelos operacionales para reducir la subcontratación (outsourcing) de los procesos de construcción de sus productos y servicios, tambien han modificado sus estructuras organizacionales para enfocarse en el cliente y han adoptado nuevas formas de trabajo conocidas como practicas agiles, derivadas de la industria del desarrollo de software, de los cuales hay muchos ejemplos como el caso de Kutxabank.
Sin embargo luego de mas de 8 años, donde hemos venido conversando, proponiendo, planteando, ejecutando y publicando sobre las estrategias de transformación en la banca, si bien hemos mejorado los procesos de desarrollo de productos y servicios financieros, aun así se sigue generando obsolescencia y sistemas legados que luego son costosos de mantener.
Ese ultimo punto es el que quiero tocar, seguimos planteando un ciclo de construcción donde hacemos un esfuerzo por desarrollar el producto y luego pasamos a una fase donde lo mantenemos, y considero que esa visión esta errada.
Creo ese es el ultimo eslabón que nos falta de pasar de proceso de desarrollo secuenciales (cascada) a procesos de evolución iterativos (ágil), y es que la visión de los procesos de construcción de software como si fuese un modelo de pasos como una fabrica (primero entiendo las necesidades [requerimientos], luego los analizo, luego diseño, luego implemento, luego pruebo, luego ajusto y finalmente entrego a producción) minimizo la necesidad de hacer revisiones de cada una de esas actividades que no son secuenciales sino continuas.
Cada vez que desarrollamos software estamos traduciendo el entendimiento de un problema del mundo en un contexto y tiempo dado, que luego representamos a traves de un modelo el cual se constituye luego en el código de la solución que luego es ejecutado en un mundo que puede tener un contexto diferente al inicial y en un tiempo diferente, por ende es necesario modificar (evolucionar) el código para ajustarlo a la nueva realidad y así volver a iterar. Debido a que secuenciamos ese proceso y lo burocratizamos, aumentamos la diferencia en el tiempo en el que observamos el mundo, lo modelamos y luego entregamos una solución que ya de por si es obsoleta.
Recomendado por LinkedIn
En la medida que nos dimos cuenta que en cada fase perdíamos contexto de los cambios que sucedían en el mundo, intentamos ajustar el modelo teniendo revisiones de las etapas anteriores.
Esas revisiones podrían generar mayor tiempo en llegar a las actividades posteriores, lo que buscamos resolver con practicas agiles, que buscan integrar dichas actividades en un ciclo de construcción mas corto, donde juntamos el diseño, la implementación, las pruebas, el despliegue o entrega en un ambiente de ejecución, donde es revisado y luego liberado o lanzado.
En este proceso de mejora en la forma en la cual entregamos soluciones de información, basadas en el desarrollo de software, aun seguimos separando al menos en la industria financiera, el proceso de desarrollo del producto, del proceso donde la solución es mantenida, incluso en algunos casos el mantenimiento de una solución en producción es realizado por un equipo de soporte, diferente al equipo que lo desarrollo, considerando que la entrega de una iteración corresponde a la liberación de una versión del producto en producción, en algunas definiciones de desarrollo de software ágil se plantea una etapa o fase de producción donde se realiza el soporte del mismo (Agile software development).
Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida
Teniendo en cuenta que esa es una situación que podemos y debemos mejorar, creo importante identificar que elementos nos pueden ayudar a hacer un cambio en la forma en como entregamos productos y servicios en la industria financiera, los cuales paso a enumerar y espero que en los comentarios me propongan algunos adicionales que haya olvidado:
Considero que entender el contexto presentado y las realizar las acciones propuestas, permitirán dar un siguiente salto en la forma en como entregamos productos y/o servicios en la industria financiera.
Espero que las personas que las apliquen en sus entidades financieras, les permitan crear una cultura de adaptación y mejora continua. Además de buscar la colaboración con empresas de tecnología con la misma vision y en conjunto con la adopción de marcos de trabajo ágiles, realizar procesos de cambio. Sin olvidar escuchar a los clientes, comprender sus necesidades actuales y como cambian, para entregar soluciones que se adapten de manera efectiva.
💡| Potencio a tus equipos y a tu empresa, un paso a la vez.
1 añoCarlos, me gustó tu propuesta. Si bien resaltas con precisión la importancia del desarrollo y mantenimiento ágil en la industria financiera, pienso que es interesante considerar los desafíos asociados con tu enfoque, especialmente en un sector tradicionalmente resistente al cambio. Bien sabemos tú y yo y quienes hemos trabajado para este sector que la seguridad, la regulación y la gestión de riesgos son aspectos cruciales en esta industria, y cualquier cambio en el software debe ser meticulosamente evaluado para evitar posibles repercusiones negativas. Así es que, aunque la adaptabilidad y la evolución constante son esenciales, también es crucial encontrar un equilibrio con la necesidad de garantizar la seguridad y cumplir con las regulaciones. Es posible sin duda. Hemos realizado los experimentos que lo demuestran. Pero también, como mencionas, la colaboración con empresas tecnológicas puede ser una solución efectiva, siempre y cuando ambas partes estén alineadas en sus objetivos y entiendan los desafíos específicos del sector financiero. Lo que he visto en casi tres décadas es que no es así. ¡Seguiremos insistiendo!
Tengo algunas ideas de tus afirmaciones mi estimado Carlos, únicamente mencionaré 2. 1: el equipo de desarrollo muchas veces no es del Banco, lo que desbarata el plan de que un equipo se convierta en esclavo de un producto hasta que deje de respirar (product roadmap - Product Management best practices). Si el caso es que un equipo de desarrollo se encargue del mantenimiento abre otra vez los problemas de soporte y desarrollo, no pueden estar de brazos cruzados esperando una falla, entonces deben desarrollar algo más, eso aumentaría la carga y desmoronaría el tiempo de respuesta. La 2 tiene que ver con Open Bank en la creación de nuevos sistemas de software. Se propende a una arquitectura modular. Lo que implica atenerse a estándares para generar piezas que se auto-ensamblen. Hay casos que vienen desde hace algunos años, al menos 16 donde se propende a disponer de "tiendas" a lo Google Store donde desarrolladores externos al Core Monolítico proveen funcionalidad modular a los sistemas y los cambios en Arquitectura han propiciado mantener el Core tal cual, puesto que las funcionalidades principales no cambian, y se construyen capas de servicios enfocadas justamente en propuestas evolutivas. ¡Gracias por compartir tus propuestas!
I will Change your Mindset || Growth @EdunoTech || EdTech Growth & Scale Strategist || Linkedin Content Creator || Building My Exceptional Personal Brand 🚀
1 añoNice Share 👍🏻
Solutions Architect: Breaking paradigms, starting from the questions to finding new opportunities for a new sustainable world.
1 añoGracias a quienes han estado leyendo el articulo, agregue otra mejora: "Para reutilizar los sistemas legados como para integrar las nuevas soluciones, los bancos pueden adoptar un enfoque diferente basado en un modelo de componentes de banca. Esta visión de componentes parte de definir bloques de construcción funcionales separados (productos o servicios internos) que pueden ensamblarse de manera flexible para crear los productos o servicios financieros al cliente final."