Arquitectura de Software en entornos de innovación y agilidad

Actualmente la sociedad está viviendo un proceso acelerado de Transformación Digital, que en palabras sencillas, es la incorporación de la tecnología en todos los aspectos de la sociedad humana. Este proceso ha ocasionado la proliferación de productos digitales que buscan satisfacer y crear nuevas necesidades tanto de personas como organizaciones.

En este contexto, el desarrollo de software es piedra angular en la construcción de estos productos, convirtiéndose esta actividad en la razón de ser de un inmenso ecosistema de startups, creadas no sólo por emprendedores, sino también por grandes empresas que ven en ellas una vía que les permite acelerar sus procesos de innovación, los cuales serían difíciles de llevar a cabo debido a su propia burocracia.

Sin embargo, mantener múltiples procesos acelerados y ágiles de construcción de software, tales como Apps, Servicios SaaS, ERP, Apis, entre otros, no es una tarea fácil. La alta competitividad de los mercados hace que los MVP (siglas en inglés de “Producto mínimo viable”) deban evolucionar rápido, incorporado nuevas funcionalidades y características para mantener e incrementar la cuota de participación. Este crecimiento continuo requiere apoyarse en una visión técnica de corto y largo plazo, aterrizada a la realidad propia de cada negocio. Para esto, una buena Arquitectura de Software se considera un factor clave de éxito.

 

¿Y cómo ayuda la Arquitectura de Software a ser Ágil?

Existe la falsa idea de que "Arquitectura de Software" y "Ágil" son fuerzas en competencia y excluyentes entre sí. En muchas corporaciones ven las áreas o responsables de arquitectura como stoppers de la agilidad; es decir, como reguladores de reglas, políticas y prácticas muchas veces cuestionadas por las áreas de negocio, pero este es otro tema digno de su propio artículo.

Contrario a este pensamiento, una buena arquitectura de software permite apalancar agilidad, ayudando a adoptar e implementar cambios (en requisitos, procesos comerciales, etc).  Si has experimentado dolor al hacer cambios, donde las partes -al parecer desconectadas- de un componente de software se rompen, sabrás que tener una base de código bien estructurado (modular y definido) convierten una buena Arquitectura en un aliado para ser ágil en la construcción de productos digitales.

 

¿Cómo abordar la Arquitectura en las etapas iniciales de un emprendimiento o proyecto de innovación?

Mark Richards, fundador de DeveloperToArchitect.com , aconseja a las startups y a cualquier entorno de innovación, focalizar los esfuerzos de la arquitectura en tres atributos: Extensibilidad, adaptabilidad y flexibilidad. Estos nos permitirán establecer como prioridad agregar nuevas funcionalidades, quitarlas o modificarlas sin dañar el sistema o partes del mismo, además de tener  capacidad de reutilización y ser portable a distintos entornos de ejecución. En la mayoría de los casos, en las primeras etapas, aspectos como elasticidad y escalabilidad no deben ser prioritarias:  “primero existo y luego escaló a mi primer millón de usuarios”.

Su enfoque se fundamenta en un diseño basado en el dominio (conocido en inglés como domain-driven design ó  DDD ), iniciando con un sistema monolito modular simple, luego transformando esos módulos a servicios de dominio utilizando una arquitectura basada en el servicio o SOA, y luego mueve esos servicios de dominio que requieren más escalabilidad, rendimiento y agilidad a microservicios cuando es necesario.

 

 

Esta evolución continua e incremental permite a las empresas nuevas sacar rápidamente funcionalidades; recuerda que en las etapas iniciales de tu proyecto es importante “aprender a fallar y aprender rápido “  para luego evolucionar la arquitectura a medida que se aprende más sobre las necesidades del mercado y se interactúa con este.

 

¿Qué ocurre con la Deuda técnica?

Un concepto importante que no debemos perder de vista es el de “deuda técnica” que, según Wikipedia, “es el costo implícito del retrabajo adicional causado por elegir una solución fácil en lugar de utilizar un enfoque que llevaría más tiempo en su desarrollo e implementación”.  Simplificando el tema se refiere a los intereses (“Horas H”) que vamos a pagar por no hacer las cosas óptimas y bien hechas desde un primer momento, y que basándonos en la subdivisión de Martin Fowler, autor de “Refactoring: Improving the Design of Existing Code”, podríamos dividirla en los siguientes cuadrantes:

Tomando esto como referencia, en un ambiente startups y agilidad todas las fuerzas iniciales están dirigidas a crear y evolucionar felices MVP, por lo que siempre será más barato, pagar los intereses de una deuda  “Consciente y Prudente” que la consecuencia de no aprender rápido testeando el mercado, por lo que simplemente se debe asumir la “deuda técnica” siendo cauteloso y pragmático aplicando sabiamente el refrán “Lo sub-óptimo es óptimo.”

 

Conclusión

La arquitectura de un software puede ser un factor clave para el éxito de un proyecto de innovación de productos digitales, con un impacto directo en los tiempo, recursos y esfuerzos del mismo, por lo que debemos elevar la conciencia de cómo construimos el “producto digital” y como va esta preparado para evolucionar.

Sin embargo, la buena “Arquitectura” debe conversar con el negocio, ser pragmática y ser un promotor de la agilidad. Evita ser extremadamente ambicioso, evitar “poner la carreta antes que los caballos”, queriendo implementar patrones y diseños arquitectónicos complejos priorizando temas como la escalabilidad y elasticidad.

En la etapa de viabilidad del producto, debería estar en primer orden la extensibilidad y adaptabilidad del software, permitiendo entregar nuevas características al mercado con mayor rapidez y evolucionando de manera orgánica. 

Leave a Comment