La ingeniería de Software ha intentado por todos los medios simplificar y organizar los procesos de arquitectura, diseño, construcción y mantenimiento de sistemas, innumerables tácticas, métodos y metodologías han salido a flote como CMMi y SCRUM pero no son suficientes y al implementarlas como una ley absoluta terminan entorpeciendo la evolución de un sistema.

Nuestra compañía por varios años se encontró con problemas habituales en la industria tradicional. Gran parte del problema parte de la generación de equipos de trabajo enmarcados a una capa especializada del sistema, como lo son TICs, Base de Datos, diseño y construcción de interfaces de usuario, diseño y construcción de APIs de comunicación y sólo unos pocos equipos enfocados en la lógica de negocio a implementar.

El problema está en que una sola parte de la solución, como lo es un módulo simple de reportes, es transversal a todos estas capas, por ende transversal a todos los equipos dado que un módulo requiere alojar datos en un sistema de base de datos, ser desplegado en una infraestructura, exponer sus servicios en un la API y ser visible desde la interfaz de usuario. Esto conlleva a requerir gran interacción entre los equipos provocando que la solución evolucione de una forma lenta y peor aún, cada equipo NO piensa en lo que es mejor para el módulo sino en que es mejor para su capa. Las áreas de TICs y Base de datos son un ejemplo icónico para visualizar este problema ya que aún sin diseñar el módulo ni conocer sus necesidades dictaminan las plataformas y base de datos a usar.

Un contratiempo al tener este tipo de equipos es la dificultad para analizar, entender y diseñar una solución entre tantos equipos. Cualquier requerimiento, por pequeño que sea, tendría que pasar por todos los equipos para que fuese diseñado de una forma óptima. Al ser esto imposible, sólo el equipo que diseña y construye la lógica de negocio es quien entiende la necesidad final, el resto de equipos al no entender totalmente el requerimiento termina por construir sus capas de cualquier forma, por esto es que una solución aunque funciona bien, no siempre es fácil de usar por el usuario, ni es fácil de interoperar con otros sistemas y los costos de mantenimiento y licenciamiento suben por no tener la autonomía de usar herramientas acordes.

En nuestro caso, antes de idear y construir nuestro Framework de MicroServicios, nos encontramos con grandes ineficiencias, evitando crear soluciones de forma ágil gracias al reproceso entre las diferentes áreas o equipos. En otras palabras, encontramos que nuestras soluciones y procesos realmente eran monolíticos, con altas dependencias y cero autonomía.

Una vez aceptado el problema, nos concentramos en aplicar los conceptos de MicroServicios como estrategia empresarial aplicada a nuestras soluciones, procesos y equipos.

Nos hemos especializado en MicroServicios por varios años, hemos aprendido de las falencias y brechas actuales, pero más importante aún, hemos madurado y construido un marco para afrontar soluciones de gran complejidad y tamaño con equipos autónomos, minimizando el tiempo y recursos necesarios y maximizando la eficiencia de nuestras soluciones.