A estas alturas ya todos hemos oído hablar de lo que es (o debería) ser un MVP, un Producto Mínimo Viable. Este, manido a estas alturas, concepto debería permitir tener un producto en manos de los usuarios de una manera rápida y, al menos en principio, a un bajo coste. Cuanto antes se utilice el producto, antes se aprende de los usos del mismo y antes podemos empezar a mejorarlo. Según esto, la mejor manera de evolucionar un producto es hacerlo accesible para su uso cuanto antes y extraer información de su uso cuanto antes. Esto mejora el resultado obtenido de realizar una, a veces eterna, fase en la que diseñamos el producto imaginando cualquier tipo de uso que pueda tener y que, inevitablemente, está abocada a concluir en un producto que no se ajusta a lo que necesitan los usuarios.
Asociado a este concepto podemos empezar a hablar de una MVA o Arquitectura Mínima Viable. Intuitivamente parece que solo el nombre nos dice lo que debería ser, y seguramente estemos en lo acertado, adaptando la frase anterior: la mejor manera de evolucionar una arquitectura es hacerla disponible para su uso cuanto antes y extraer información de su uso cuanto antes. Vendría a ser una arquitectura suficientemente buena para que el producto sea lanzado y que necesitará ser continuamente mejorada. Implica la implementación de los componentes arquitectónicos básicos que conforman la base de la arquitectura de tal manera que el resultado final es lo suficientemente bueno para ser lanzado. El resto de la arquitectura puede entonces construirse sobre estos cimientos. De este modo, se priorizan y cumplen los requisitos más importantes del usuario final, tanto funcionales como no funcionales.
Es habitual que a la hora de desarrollar un MVP, promovidos por esa velocidad que buscamos, de forma consciente o inconsciente estemos tomando decisiones que nos conducen, directamente a la falta de una arquitectura, o al menos, de una definida.
La razón para que esto ocurra podría ser la presión por la entrega de funcionalidad, centrando todo en el corto plazo buscando el afamado TimeToMarket.
La otra cara de la moneda sería tratar de diseñar toda la arquitectura por adelantado, intentando pensar en lo que podría necesitarse dentro de un año, dentro de dos años, etc. Y luego la mayor parte acaba en la papelera porque el trabajo se basa en suposiciones y no en requisitos reales.
Si os dais cuenta, en este último punto acabamos de describir uno de los problemas que Agile venía a resolver y que no debería tener mucho sentido cuando estamos hablando de construir un MVP.
La razón para que esto ocurra puede ser que no veamos que un exceso de arquitectura puede obstaculizar precisamente la velocidad que deseamos. Puede que gastemos demasiado de nuestro precioso tiempo en conseguir una arquitectura a prueba de bombas cuando tal vez lo que necesitemos sea un chaleco salvavidas.
Ahora vendría la pregunta de cómo se relaciona esta Arquitectura Mínima Viable con un iPaaS (Integration Platform as a Service), como puede ser Anypoint Platform.
Si partimos de la pregunta de qué es un iPaaS, lo definimos como una plataforma basada en la nube que conecta varias aplicaciones, sistemas y tecnologías dentro de la nube o en las instalaciones empresariales. Permite la implementación y el mantenimiento de los flujos de integración sin la necesidad de hardware o middleware.
Si lo ampliamos un poco más a Anypoint Platform, podemos decir que es una plataforma híbrida que trata de solucionarte, de caja, todos los problemas más conocidos que puedes tener a la hora de implementar tu arquitectura de integración. Trata de solucionarte cosas como:
Y es en estas soluciones de caja donde podemos empezar a ver la relación con un MVA. La implementación de uno de estos iPaaS puede tomarse como, al menos la base o los principios, de esta MVA. Estas soluciones ya conocidas y probadas empiezan a formar la lista de esos componentes arquitectónicos básicos que hemos dicho que forman el MVA, y sobre los cuales se empieza a formar nuestra propia arquitectura. Disponer de estos componentes desde el principio puede ser una ventaja enorme en aras de conseguir la ansiada velocidad para disponibilizar nuestra arquitectura y empezar a evaluarla cuanto antes.
Es fácil ver cómo, en un contexto de Arquitecturas de Integración, la implementación de un iPaaS, con los ajustes necesarios para la organización, producto o sistema concreto, nos da la base para empezar a crear nuestras soluciones de una manera ágil y rápida, pudiendo construir productos sobre una base firme que irá evolucionando en el tiempo.
Incluso en el caso de Anypoint Platform, MuleSoft y su enfoque API-led Connectivity podemos empezar a construir con una mentalidad concreta y definida para crear una arquitectura lógica preparada para el cambio y para el santo grial de la reusabilidad.
Pero no olvidemos las características que comentamos que tenían estas MVA, que se basan en requisitos concretos y conocidos. Seguramente, si el futuro es incierto, será mejor acometer los problemas iniciales tal y como son, pero a la vez, no deberíamos renunciar a la calidad.
Como siempre, deberemos pensar en el tipo de trade-off que deberemos tomar.
ifgeekthen.nttdata.com es un blog del grupo NTT DATA. Un proyecto que busca compartir con profesionales del mundo digital temas relacionados con la tecnología y el universo geek.
