De un software monolítico a una arquitectura MACH moderna
En la primera parte, explicamos qué es MACH y por qué las empresas pueden beneficiarse de una arquitectura MACH.
En este artículo de seguimiento, le mostraremos para qué empresas es más adecuado MACH, cómo podría ser la transformación de una arquitectura de software monolítica a una arquitectura MACH y qué empresas ya se han convertido con éxito a la arquitectura MACH.
¿Cuándo tiene sentido MACH?
Para las empresas que están empezando a digitalizar sus canales de venta, tienen un modelo de negocio sencillo con una o dos marcas propias, pocos conocimientos técnicos y quieren probar el comercio electrónico por primera vez, una solución centralizada lista para usar es probablemente la mejor solución.
Las empresas más maduras desde el punto de vista digital que: tienen requisitos de canales digitales y modelos de negocio complejos; tienen un alto nivel de madurez técnica; y necesitan aplicaciones modernas y flexibles se beneficiarían del cambio a una arquitectura MACH.
A continuación se muestra una comparación de las arquitecturas monolíticas y MACH basada en Amplience:
De una arquitectura de software monolítica a una arquitectura MACH
En última instancia, la transformación de una arquitectura de software monolítica a una arquitectura MACH depende siempre de cada caso.
Paso 1
Comenzar con headless
Se ha demostrado que es útil convertir primero el front-end a headless antes de pasar a las áreas posteriores. Muchos marcos de comercio como commercetools o SAP Commerce ofrecen una variedad de APIs que pueden ser utilizadas e implementadas por el front-end y permitir así un comienzo rápido.
Si todavía no se dispone de un sistema CMS adecuado, la planificación prospectiva también es útil en este caso y debería comprobarse si en el futuro se van a construir otros componentes, como una plataforma de compromiso digital o una plataforma de datos de clientes. ¿Quiere también el mejor de su clase? o ¿tiene sentido elegir un CMS que quizá proceda de la misma empresa y se integre fácilmente en una plataforma de datos del cliente o una plataforma de experiencia digital?
Paso 2
Intercambiar datos que cambian con frecuencia a través de APIs
Si el front-end se ha convertido a headless, es importante comprobar qué otras aplicaciones deberían o deben conectarse a través de APIs. Es aconsejable concentrarse primero en los datos que cambian con frecuencia, como el precio o los datos de inventario del sistema ERP, y examinar después los datos que cambian con menos frecuencia, como las imágenes o los títulos de los productos.
En general, siempre se debe definir el impacto empresarial de cada aplicación y cambiar primero el sistema con mayor impacto a la comunicación basada en APIs.
Paso 3
Desarrollo en la nube y creación de microservicios
Los nuevos microservicios deben desarrollarse y estar disponibles en una arquitectura en la nube para facilitar su uso por otras áreas. La conversión de los servicios back-end del comercio en mircoservicios modernos y flexibles tiene sentido en el caso de los requisitos de los clientes que cambian rápidamente o en el del uso solapado de servicios, como un sistema de fidelización que se utiliza a través de varios canales, por ejemplo, TPV, tiendas online y apps.
El uso de APIs y potencialmente nuevos microservicios en una arquitectura en la nube conlleva muchas ventajas para la empresa y, en última instancia, también para la experiencia del cliente.
En primer lugar, se dispone del desarrollo independiente del front-end y de los servicios descendentes, en los que pueden trabajar simultáneamente varios equipos. En segundo lugar, también se beneficia de la simplificación de esos servicios y de la escalabilidad simplificada de nuevos servicios.
Todo ello se traduce en una respuesta más rápida a las demandas del mercado y en un despliegue más rápido de nuevas funciones.
Si desea obtener más información sobre los principios subyacentes, como microservicios, APIs, comercio en la nube, comercio Headless y arquitectura basada en eventos, puede consultar nuestro primer artículo sobre el tema.
¿Qué significa la arquitectura MACH para su proyecto?
La gestión de proyectos es más compleja
- La integración de distintos sistemas también implica reunir a distintas partes interesadas del lado del cliente y del proveedor de servicios.
- Esto significa que también deben estar disponibles durante el transcurso del proyecto.
- La determinación del alcance requiere un alto grado de precisión, hay que tener en cuenta todos los sistemas y procesos relacionados y los flujos de datos.
La coordinación entre los equipos de desarrollo debe ser adecuada
- Los equipos de desarrollo separados son posibles y, de hecho, necesarios, pero las dependencias técnicas deben definirse claramente y tenerse en cuenta, por ejemplo, la conexión del front-end y el back-end a través de interfaces.
Definición de los flujos de información y datos necesarios
- Los flujos y orígenes de los datos deben estar claramente definidos. Esto parece sencillo y lógico, pero a menudo resulta complejo cuando se trata de sistemas evolucionados. El almacenamiento redundante de datos y las soluciones aisladas son un no-go cuando se desarrolla una arquitectura headless.
Empresas que se han pasado a la arquitectura MACH
Amazon, ahora la mayor plataforma de comercio electrónico del mundo, empezó como una humilde librería. Una plataforma todo en uno de dos niveles encajaba perfectamente en esta, entonces, pequeña empresa. Sin embargo, cuando Amazon empezó a crecer, se enfrentó a un problema acuciante con la escalabilidad del sistema. Los cuellos de botella típicos, como las largas implementaciones, las grandes bases de datos difíciles de gestionar, los problemas para añadir nuevas funciones y el tráfico fluctuante del sitio web retrasaron el crecimiento de la empresa.
Zalando alcanzó su capacidad en 2010. La empresa ya había pasado de ser una modesta tienda a una marca de moda popular en todo el mundo. Su actual sistema de comercio electrónico ya no podía soportar la carga. El cambio a los microservicios dio a Zalando la oportunidad de acelerar la integración de nuevas innovaciones y realizar pruebas A/B para lograr la mejor conversión posible.
REWE escala su mercado de comestibles en línea con una arquitectura MACH flexible. En 2020, la empresa utilizó MACH para duplicar su número de servicios click-and-collect en tan solo unas semanas, lanzar una plataforma de cumplimiento intersectorial y, en última instancia, proporcionar un acceso cómodo a los comestibles en toda Alemania en un momento muy crítico.
Netflix fue una de las primeras empresas en darse cuenta de que una arquitectura monolítica no es una solución óptima para una aplicación compleja, ya que los componentes de una aplicación monolítica están estrechamente interconectados y un solo fallo puede provocar varios días de inactividad. En el negocio del vídeo a la carta, esto es un factor decisivo para los usuarios y el riesgo era demasiado alto para asumirlo.
Conclusión
Normalmente es necesario un análisis de las necesidades internas (clientes) y externas (empleados) para definir y luego implantar una arquitectura adecuada.
Aquí es donde entran en juego nuestros muchos años de experiencia en SQLI. Conocemos los retos a los que se enfrentan las empresas y trabajaremos en colaboración para desarrollar la infraestructura que optimice procesos tradicionalmente fragmentados.
Pero no existe una solución única. Cada empresa es diferente, por lo que llevaremos a cabo una evaluación exhaustiva para valorar la preparación, los riesgos, las ventajas y, lo que es más importante, el rendimiento de la inversión, y lo que esto significa para su empresa.
¿Quiere saber más? Descubra las diferencias entre la arquitectura Monolítica, el comercio Headless y la arquitectura Composable. Descargue ahora nuestro completo Whitepaper.