Secretos sucios del comercio sin cabeza: lo que algunos vendedores intencionalmente no dicen

Los sucios secretos de las soluciones de comercio sin cabeza: lo que algunos proveedores (intencionalmente) no le dicen puede costarle mucho.

El comercio sin cabeza, o, simplemente, "sin cabeza", es el favorito del mundo B2C en este momento. Según Google Trends, las solicitudes de búsqueda para el comercio sin cabeza han crecido exponencialmente desde principios de 2020. Desde el punto de vista del comercio electrónico, es fácil ver por qué.

Los consumidores han estado confinados en sus casas, atados a sus redes sociales durante la pandemia. Las marcas directas al consumidor pueden aprovechar medios como Instagram, TikTok o Facebook y llevar sus productos directamente a su público objetivo. Las soluciones de comercio sin cabeza son una obviedad.

Las arquitecturas sin cabeza proporcionan una gran flexibilidad. Debido al desacoplamiento del front-end y el back-end (y la disponibilidad de las API), es mucho más fácil para las organizaciones que desean implementar el comercio en nuevos canales hacerlo con una plataforma que admita headless.

Las soluciones de comercio sin cabeza también brindan una mayor agilidad ya que el frontend y el backend se implementan por separado. Dado que la agilidad se ha convertido en un tremendo diferenciador empresarial, está aumentando el interés por los sistemas sin cabeza.

Soluciones de comercio sin cabeza: cortar con la exageración

Pero, ¿qué es exactamente el comercio sin cabeza? Como suele ser el caso en los mundos de la tecnología y el marketing, existe una tendencia a aferrarse a la última palabra de moda brillante (piense en big data o inteligencia artificial/aprendizaje automático hace un par de años) e inyectarla en tantas conversaciones como sea posible. .

Sin embargo, cuando las personas realmente no pueden definir qué es una cosa, las aguas alrededor de esa cosa tienden a volverse bastante turbias. Eso es exactamente lo que está pasando con el comercio sin cabeza.

No podemos ser demasiado duros con los especialistas en marketing; no son los únicos que enturbian las aguas. Muchos proveedores están agregando a la mezcla, intencionalmente o no, al combinar sin cabeza, en la nube, API y microservicios. Tienen sus agendas, por lo que les conviene difuminar las líneas entre estas cosas. Y para ser claros, ninguno de ellos es igual.

En pocas palabras, el comercio sin cabeza significa:

1. El frontend/escaparate/vidrio está desacoplado del motor de comercio (es decir, el backend).
2. Dado que está desacoplado, consume capacidades de back-end como precios y promociones a través de llamadas API.
3. Por lo tanto, por definición, para que una plataforma de comercio pueda admitir implementaciones sin cabeza, necesita cobertura API de la funcionalidad de back-end de comercio.

Entremos y echemos un vistazo más de cerca a qué es exactamente headless (y qué no es), de dónde viene y para quién es.

El comercio sin cabeza no es nada nuevo

Si bien el término en sí solo podría haber comenzado a cobrar fuerza en los últimos años, el concepto de headless no es ni remotamente nuevo. Como se mencionó anteriormente, es un enfoque que prioriza la API en el que el front-end/capa de presentación/vidrio se desacopla del núcleo (usando las API).

Por ejemplo, en SAP (y anteriormente en Hybris), hemos estado habilitando capacidades de comercio a través de nuestra capa Restful API (Omni-Commerce connect) durante más de una década. Aproximadamente la mitad de los más de 3500 clientes que ejecutan SAP Commerce (en las instalaciones y en la nube) lo hacen de manera autónoma con un CMS de terceros o un escaparate desacoplado a medida.

El punto es, no se deje engañar por el zumbido; headless no acaba de aparecer en escena.

Las soluciones de comercio puro sin cabeza no son para todos

Sin cabeza, como con todo lo demás, no es para todos. Es complejo, para empezar. Los desarrolladores deben tener conocimientos profundos y amplios en múltiples bases de código.

Pero eso no es todo. Requieren madurez de TI y capacidad de desarrollo, ya que una capa de presentación/escaparate a medida debe construirse completamente desde cero utilizando marcos y bibliotecas front-end (como Angular/React/Vue) o a través de una solución de socio como mínimo. Estas interfaces personalizadas generalmente no son compatibles con el proveedor.

Además, las interfaces personalizadas suelen limitar la capacidad de los profesionales de negocios para diseñar y actualizar la interfaz sin la ayuda de TI. Si esa es una consideración importante para su negocio, es posible que las soluciones de comercio solo sin cabeza no sean una buena opción para usted.

La buena noticia: los proveedores ofrecen capacidades "sin cabeza y sin cabeza" con una cobertura de API del 100 % y una tienda desacoplada sin necesidad de construirla desde cero. Este enfoque acelera el desarrollo de la interfaz y el cronograma general de entrega del proyecto.

Sin cabeza no es igual a microservicios

Como mencionamos al principio, algunos proveedores están enturbiando las aguas intencionalmente al combinar headless con microservicios. Dejemos las cosas claras.

No, los microservicios NO son equivalentes a las API. Y no (estoy a punto de usar mi voz "externa" aquí), UNA ARQUITECTURA BASADA EN MICROSERVICIOS NO ES UN REQUISITO PREVIO PARA HEADLESS (las API, por otro lado, lo son).

Según Martin Fowler, "el estilo arquitectónico de microservicio es un enfoque para desarrollar una sola aplicación como un conjunto de pequeños servicios, cada uno ejecutándose en su propio proceso y comunicándose con mecanismos ligeros, a menudo una API de recursos HTTP".

Leíste bien: los microservicios exponen sus capacidades a través de las API y, como tales, son conceptos complementarios, no intercambiables. Compare una arquitectura basada en microservicios con una arquitectura monolítica en la que toda la aplicación consta de "una pieza" de código. En el mundo real, pocas aplicaciones están completamente basadas en microservicios o son completamente monolíticas; normalmente caen en algún lugar en el medio.

Si bien los microservicios pueden hacer muchas cosas, también son costosos (muchos gastos generales) y de ninguna manera son una bala de plata para la agilidad. Sin entrar en los pros y los contras de cada patrón arquitectónico, vale la pena señalar que la principal ventaja de una arquitectura basada en microservicios es la velocidad y la agilidad con la que las grandes organizaciones de desarrollo pueden crear software. La sobrecarga es pequeña en comparación con el tiempo de desarrollo de código en una arquitectura monolítica.

Por lo tanto, es bastante valioso para un proveedor de plataformas de comercio como Amazon, que normalmente tiene cientos de desarrolladores trabajando en él. Sin embargo, este tipo de arquitectura no funcionaría bien para todos. Es una opción particularmente mala para las organizaciones que no tienen las habilidades de TI y los recursos de desarrollo de comercio correspondientes para beneficiarse de ella.

Es mejor considerar lo que Gartner llama la arquitectura empresarial componible. Este modelo de bloques de construcción intercambiables permite que una empresa se reorganice según sea necesario, según factores como un cambio en los valores del cliente o un cambio repentino en la cadena de suministro o los materiales. Estos bloques de construcción o módulos pueden ser micro, pero también macroservicios.

Según Gartner, esta arquitectura proporciona: velocidad a través del descubrimiento, mayor agilidad a través de la modularidad, mejor liderazgo a través de la orquestación y resiliencia a través de la autonomía. Esto no podría haber sido más importante que durante la pandemia, cuando las organizaciones tuvieron que repensar por completo y modificar sus modelos comerciales en cuestión de días o correr el riesgo de quebrar.

Ahora, si se pregunta por qué algunos proveedores están combinando headless con microservicios, la respuesta es tan antigua como el propio mercado de software empresarial. Al enfatizar una nueva capacidad brillante, permite a los proveedores emergentes desviar el enfoque de las capacidades en las que se quedan cortas, como la plataforma y la solidez de las características.

Y si bien una arquitectura moderna es definitivamente una consideración importante al seleccionar una plataforma de comercio, no puede ser a expensas de la riqueza funcional o la capacidad de empoderar a los usuarios comerciales.

Sin cabeza llegó para quedarse

A medida que la cantidad de puntos de contacto continúa creciendo, el comercio sin cabeza no irá a ninguna parte. Al seleccionar una plataforma, considere todos los requisitos funcionales y no funcionales aplicables a su negocio, no solo hoy, sino también mañana.

Seleccionar una plataforma que podría hacer el trabajo hoy pero que no respaldará su crecimiento en el futuro ( por ejemplo, la localización internacional ) es miope y solo resultará en patear la lata proverbial en el futuro.

Finalmente, el hecho de que algunos proveedores quieran que mire el objeto brillante y brillante no significa que los otros requisitos de repente no importen. La gestión de información de productos, la gestión de contenido web, la gestión de pedidos, las capacidades B2B, las capacidades B2C y la personalización son esenciales.

No caiga en la trampa de combinar funcionalidad robusta con arquitectura heredada, a pesar de lo que digan algunos proveedores.