Una guía para líderes digitales

CMS Headless en la empresa

Qué considerar antes de iniciar un proyecto de plataforma de CMS headless en una empresa

¿Qué es un CMS Headless?

Headless suena pegadizo, pero ¿qué significa realmente? ¿Se supone que la parte delantera es la cabeza y la parte trasera el resto del cuerpo? Definitivamente es muy visual.

Para ser específicos, el CMS Headless es un sistema de administración de contenido (CMS) que no se enfoca en la entrega de contenido a través de páginas, sino únicamente en el trabajo de back-end: brinda a los creadores de contenido las herramientas para llevar sus flujos de trabajo hasta un punto donde el contenido está listo para ser consumido en un caso de uso de Contenido como Servicio. Es básicamente un CMS regular amputado de su capa de entrega web: sin sistema de plantillas, sin entrega de HTML y sin administración de la estructura y el estilo del sitio. Un CMS Headless se enfoca naturalmente en ayudar a los usuarios con las siguientes tareas:

  • Modelar el contenido
  • Creación y autoría de contenido.
  • Facilitar el flujo de trabajo y la colaboración en torno al contenido (incluidas las traducciones)
  • Organización del contenido en el repositorio (semántica, colecciones, taxonomías)

Y deliberadamente, el contenido como servicio no toca cómo se entregará o presentará el contenido en el front-end a los usuarios finales.

Introducción

La gestión de contenido headless es una tendencia que existe desde hace ya un tiempo. Ya es un elemento básico para implementaciones boutique para empresas más pequeñas y sitios web para campañas, y también continúa ganando terreno en proyectos empresariales.

Pero antes de sumergirte de lleno en un proyecto de CMS Headless, debes considerar cómo se adapta a las necesidades de tu organización. Al igual que mucha jerga de TI, el término "CMS Headless" no está bien definido. Antes de comenzar, es bueno tener una descripción general rápida de algunos de los conceptos utilizados:

• API de contenido: una herramienta utilizada por los editores para administrar contenido que proporciona una fuente de contenido sin procesar para que la consuman otras herramientas de desarrollo, no para los usuarios directamente.

• Capa de visualización: un sistema (o sistemas) que procesan el feed proporcionado por una API de contenido para que se muestre a los usuarios. Un sitio web o una aplicación móvil, por ejemplo.

Para estos dos componentes, hay una serie de opciones en el mercado. Para obtener más información sobre las diferentes opciones de la API de contenido puedes consultar
nuestro eBook: Una guía del usuario empresarial sobre el contenido como servicio.

Para las capas de visualización que consumen contenido proporcionado por la API, el panorama es aún más diverso y puedes optar por una interfaz personalizada.
Consulta el siguiente bloque para conocer algunas tecnologías populares que se utilizan para los front-end web para los CMS Headless.

Juntas, la combinación de una API de contenido y una capa de visualización dan como resultado una implementación de CMS Headless. Esto difiere de un CMS típico y tradicional donde la API de contenido y la visualización se han acoplado más para formar un solo sistema.

Ambos enfoques tienen sus ventajas y desafíos, algunos de los cuales discutiremos. Aquí cubrimos las consideraciones que debes tener en cuenta antes de iniciar un proyecto de CMS Headless en una empresa.

Tecnologías utilizadas para construir un front-end (capa de visualización) para un CMS Headless:


Static site generators:
Estos generan un conjunto de archivos HTML mediante un proceso de publicación. Alta escalabilidad a bajo costo. Muy seguro, pero puede ser limitante para funciones dinámicas o cuando se deben aplicar permisos de nivel de usuario para acceder al contenido
Productos populares: Gatsby.js, Hugo, Jekyll

JavaScript server-side frameworks:
Un framework web que se ejecuta en un servidor. Obtiene contenido de forma dinámica desde la API de contenido. Alta flexibilidad para integraciones, permisos, etc. Requiere un alojamiento
medio ambiente y mantenimiento activo.
Productos populares: Express, Next.js, Koa

Function as a Service (FaaS):
Un framework simplificado que está completamente administrado. Escala de precios y rendimiento con el uso. El panorama para el uso de front-end de CMS sin cabeza es inmaduro y requiere cierta inversión en desarrollo personalizado. Una situación de bloqueo de proveedor también es algo a considerar.
Productos populares: Azure Functions, AWS Lambda, Google Cloud, Open FaaS

background image

De Killer Apps a Killer API

Hoy en día, la industria de gestión de contenido está madura, lo que significa que existe mucha experiencia acumulada y mejores prácticas. Esto, a su vez, hace que los proyectos de implementación de CMS sean un trabajo rutinario relativamente monótono en el mundo de TI.

Los desafíos están en la lógica comercial, mientras que la tecnología en sí misma puede no parecer muy emocionante para los tecnólogos. Aprovechando la ola de la economía de las API, las herramientas de administración de contenido autónomas desafían el statu quo y brindan un enfoque alternativo para la entrega de contenido.

Las API (interfaces de programación de aplicaciones) han existido desde el comienzo de la informática. En el pasado, la mayoría de las API eran internas y se usaban para desarrollar software en estrecha proximidad: las aplicaciones que se ejecutan en Microsoft Windows usan sus API para interactuar con el hardware.

El entusiasmo reciente en torno a las API se debe principalmente a las distribuidas que utilizan tecnologías web. El CMS sin cabeza es una manifestación de esta tendencia para la gestión de contenido.

Pero al igual que una API en un sistema operativo de escritorio, una API web en sí misma es solo una herramienta. El valor radica en las características y funcionalidades que se pueden construir utilizando sus capacidades. Las API de Windows permitieron a los desarrolladores crear aplicaciones increíbles que permitieron a Microsoft dominar la informática durante más de dos décadas.

Con la llegada de la web y los smartphones, el sistema operativo de escritorio perdió su posición dominante. La empresa tuvo que adoptar y dejar de depender de Windows para seguir siendo relevante y ser parte del nuevo mundo que presentaba servicios en la nube y precios basados en suscripciones para su paquete de productividad de Office.

Pero las cosas rara vez son en blanco y negro. Si bien la informática de escritorio ciertamente no es una industria en crecimiento, hay áreas en las que sigue siendo la mejor opción, desde campos que requieren precisión en tiempo real, como hacer música, hasta tareas mundanas como escribir publicaciones en blogs y realizar trabajos de productividad aleatorios. La posesión de computadoras personales ha alcanzado un punto de inflexión y está en declive; sin embargo, la gran mayoría de los trabajadores de oficina continúan manejando una computadora de escritorio o portátil todos los días.

Esta historia también es una analogía con el espacio de gestión de contenido. Es fácil para los proveedores de CMS arraigados señalar las capacidades que faltan en los sistemas puros sin cabeza, mientras que los equipos de marketing de los proveedores de CaaS trabajan para producir contenido que subraya las deficiencias de los productos de "CMS heredados". En realidad, hay espacio para ambos enfoques. Es un campo diverso con diferentes requisitos y casos de uso.

En Ibexa, no vemos la necesidad de la yuxtaposición. Nuestra infraestructura de productos nos permite construir nuestras API internas y luego exponerlas a través de API web como REST o GraphQL. Puedes usar Ibexa DXP php  CMS Headless, full stack o algo intermedio. La decisión es tuya.

 

 

Necesidades del usuario y capacidad del productos

Una plataforma CMS Headless se usa principalmente para administrar contenido


Hoy en día, el término CMS (Content Management System) se usa para describir un sistema cuya función va mucho más allá de crear, modificar y editar contenido.

Estos sistemas han superado su alcance inicial, y muchos ahora están en camino de hacer la transición de un CMS a una DXP (Plataforma de experiencia digital). Este tema se trató en profundidad en una publicación de blog titulada From CMS to DXP to Deliver Digital Success.

Un CMS Headless es más fiel a su definición. Es un sistema utilizado principalmente para la GESTIÓN DE CONTENIDOS. Esto lo hace más accesible para los usuarios, pero también menos capaz que un CMS empresarial tradicional.

Esta ambivalencia de lo que hace un CMS puede crear algunas sorpresas durante el proceso de implementación. Es posible que des por sentadas algunas funciones que están (y siempre han estado) fuera del alcance de un sistema de gestión de contenido.

Al reemplazar un CMS o DXP tradicional existente con una solución de CMS Headless, una tarea importante es identificar las tareas que sus editores de contenido, personal de marketing y otros usuarios realizan a diario.

Mapee cualquier brecha de características entre los dos en funcionalidades clave. Además de las necesidades de administración de contenido, como modelos de contenido enriquecido y flujos de trabajo, asegúrate de asignar funciones para tareas de administración de sitios periféricos, como:

  • Administrar la navegación, los redireccionamientos y otras tareas similares
  • Agregar scripts de seguimiento para marketing, seguimiento de usabilidad, etc.
  • Gestión de usuarios con su backend de usuario corporativo
  • Programación de promociones para los fines de semana
  • Modificación de las estructuras de la página de destino
  • Vista previa del contenido y una colección de
    elementos de contenido

Todo lo anterior se puede lograr con un sistema integrado o una combinación de una API de contenido y una capa de visualización. La diferencia es que para este último es posible que deba agregar herramientas de terceros e integraciones adicionales.

No dés por sentadas las características del producto cuando estés pasando de un paquete de software integrado a una arquitectura de microservicios construida a partir de componentes individuales altamente especializados.

Organizations are moving away from monolithic enterprise applications in favor of suites of loosely coupled services so that they can align their technology to their exact content management needs and respond quickly to new requirements
Damian Hess
Enterprise Knowledge

Complejidad y robustez de la implementación

Se requiere una combinación de las habilidades y la tecnología adecuadas


Debido a su madurez, las implementaciones tradicionales de CMS de grandes proyectos son más fáciles (¡no fáciles!) de estimar que un proyecto de implementación headless de alcance similar. Esto no se debe a que la tecnología sea mejor o peor, sino a que hay formas de trabajar más establecidas, expectativas de lo que hace un sistema y quién hace qué. Uno puede confiar en la experiencia pasada en lugar de las conjeturas para estimaciones realistas.

Hoy en día, este no suele ser el caso de las implementaciones headless complejas. El cliente a menudo realiza este tipo de implementación por primera vez y es posible que el socio de integración no tenga suficiente experiencia.

Esto puede generar algunos contratiempos y costos inesperados durante y después del proyecto, incluso si ha realizado la debida diligencia en las funciones como se describe. Bien administrado, estos no son un problema.

Una característica clave de un proyecto de CMS es que lo más probable es que sea un proyecto de múltiples proveedores que utilice múltiples tecnologías. Si bien algunos proveedores de CMS realizan proyectos de implementación por sí mismos, es bastante raro que un proveedor de CaaS (Contenido como servicio) brinde servicios de implementación.

Simplemente no es algo que sea compatible con el modelo de negocio de un proveedor de API. Al igual que con cualquier proyecto de tecnología, debe examinar un
la experiencia y las referencias del socio de implementación usando la API de contenido de su elección. No querrás ser su primer intento.

La arquitectura de integración es otro punto a considerar. Los sistemas de gestión de contenido han sido tradicionalmente sistemas del lado del servidor, y es natural que las conexiones a sistemas externos se hayan creado en el servidor.

Una tendencia emergente es trasladar las integraciones al cliente: el navegador. Esta tendencia no está directamente relacionada con si está utilizando una plataforma de CMS headless o no, pero los dos suelen coincidir en los mismos proyectos porque ambos son tecnologías novedosas.

JAMStack es un apodo dado al enfoque arquitectónico técnico en el que el navegador se convierte en la plataforma de integración. El término proviene de JavaScript, API y Markup (JAM). La idea central es buscar los mejores proveedores de API para la autenticación, el comercio electrónico, los pagos, etc. e integrarlos en el navegador, liberándolo de la ejecución de sistemas del lado del servidor.

En el mejor de los casos, una implementación de JAMStack te permite flexibilidad para elegir la mejor tecnología a bajo costo; en el peor de los casos, es un frágil lío de servicios que puede llevar mucho tiempo para descubrir cuándo hay problemas. En realidad, es probable que la experiencia promedio se encuentre en algún punto intermedio.

Costos de mantenimiento a largo plazo y del proyecto

Presta atención al costo total de propiedad y al presupuesto para el crecimiento


El costo de una implementación de CMS sin cabeza se reduce al costo de la API de contenido y los consumidores de la API. El costo total se acumula durante la fase de desarrollo inicial y durante los años de desarrollo y mantenimiento.

La API de contenido es más fácil de entender, ya que deberá considerar las opciones disponibles en el mercado y elegir la que le brinde la capacidad y las características requeridas al precio más competitivo. Un juego de números, más y menos.

Al elegir una API de contenido, asegúrese de tener en cuenta al menos los siguientes puntos:

•   Capacidad requerida (número de elementos de contenido, repositorios, editores...)
•   Funciones disponibles frente a desarrollo personalizado
•   Costo de alojamiento (para proveedores de CMS)
•   Costo de suscripción (para CaaS)

Aquí debe encontrar la solución con el mejor equilibrio para sus necesidades individuales.

El precio de un proveedor de CaaS puede ser muy atractivo a bajo volumen, pero puede dispararse a la escala que su organización necesita. La falta de tarifas de licencia de un sistema de código abierto puede compensarse con un mayor costo de alojamiento. Asegúrate de calcular los gastos futuros si tu deseo es el crecimiento.

Una PaaS como Ibexa Cloud, por otro lado, podría proporcionar un beneficio de costo sobre los proveedores de IaaS al reducir el costo de personal de administrar tu propio equipo interno de DevOps.

Con un proveedor de API de contenido elegido, es hora de considerar la capa de visualización. Esta es un área donde hay literalmente un sinfín de opciones disponibles.

Desde compilaciones boutique completamente personalizadas hasta implementaciones basadas en productos basadas en marcos como Next.js o Nuxt.js hasta generadores de sitios estáticos como Gatsby.js o Hugo. Prácticamente todas estas herramientas son de código abierto, por lo que el costo se basa en la mano de obra. Una vez más, busca experiencia al seleccionar un partner de implementación, ya que produce una mayor calidad y una mayor velocidad de desarrollo.

Por el costo a largo plazo, las cosas pueden volverse complicadas. Los costos de la API de contenido están sujetos a cambios; en general, los precios suelen ser bastante estables, pero técnicamente un proveedor de CaaS podría aumentar los precios literalmente de la noche a la mañana en función de los términos de suscripción que haya acordado.

Sin embargo, esto es bastante improbable porque hay muchas alternativas y moverse entre proveedores es relativamente trivial. Necesitarás volver a trabajar en su implementación, pero una capa de visualización de contenido bien diseñada, "la cabeza", puede adaptarse a esto sin introducir un costo prohibitivo.

Arquitecto para el cambio de forma continua

Aprovecha los beneficios de un entorno de microservicios

En una solución de CMS headless, la capa de visualización (API Consumer) se convierte en una opción estratégica. Al implementar un CMS tradicional, las plantillas y la implementación del front-end a menudo son desechables.

En las implementaciones empresariales en las que un sistema de administración de contenido web (WCMS) puede estar activo durante cinco a 10 años después del proyecto de implementación inicial, el diseño se somete a múltiples actualizaciones desde cero. En el backoffice, las características siguen sumando.

En una solución integrada de administración de contenido de un extremo a otro, la API de contenido y la capa de visualización están, por naturaleza, estrechamente acopladas: son parte del paquete.

Una de las propuestas de valor clave de la arquitectura headless es que los dos son independientes. Pero existe una tendencia natural a que las inversiones en funciones se acumulen en la capa de visualización, lo que hace que el objetivo original de ser independiente para intercambiar cualquiera de los componentes sea un punto discutible.

Si acopla estrechamente su implementación a una capa de diseño dada, puede terminar con un costo creciente. Con el tiempo, su capa de visualización acumula deuda técnica, lo que a su vez requiere mayores esfuerzos de desarrollo.

Tu capacidad para evolucionar se ve obstaculizada y podría haber una gran reescritura en las cartas. Es fácil vivir en la ilusión de tener un sistema desacoplado simplemente por la arquitectura de alto nivel que elegiste inicialmente. Mantenerse ágil requiere esfuerzo. Por naturaleza, el software está destinado a quedar obsoleto tarde o temprano, pero puede diseñar un sistema para que las piezas sean reemplazables.

La clave para mantener la flexibilidad de una implementación headless es desarrollar conscientemente funcionalidades que sean desechables. Divide capacidades complejas en servicios reutilizables que no estén vinculados a ninguna capa de visualización determinada. Esto te permitirá aprovechar los beneficios del enfoque desacoplado incluso durante años de desarrollo.

background image

Conclusión

Es esencial invertir en un DXP modular con sólidas capacidades de contenido y API abiertas

Hoy hay más opciones que nunca para una implementación técnica de una solución de TI empresarial. El enfoque headless puede ser una bocanada de aire fresco para alguien que trabaja con un sistema engorroso cuya vida útil técnica está mucho más allá de su fecha de caducidad, pero no siempre es necesariamente la mejor combinación.

La abundancia de opciones puede hacer que sea más difícil elegir la opción correcta, y puede ser fácil elegir algo que no sea la pareja ideal. Por ejemplo, si solo publicas contenido multicanal, no necesitas la administración del sitio, entonces la implementación de un CMS headless es la opción perfecta. No pague por funciones de CMS headless que no necesita.

Al mismo tiempo, tenga en cuenta que tener una nueva opción disponible no hace que las herramientas existentes queden obsoletas. Si bien las características se vuelven genuinamente obsoletas, hay funcionalidades que son esenciales, una especie de mal necesario, para tener en la implementación de un proyecto de gestión de contenido.

Para estas necesidades, puede usar funciones de ofertas integradas como DXP o optar por una plataforma de CMS sin interfaz pura e integrar herramientas de terceros para llenar los vacíos. En proyectos grandes que agregan más sistemas, los partners y los sistemas se suman y pueden comenzar a consumir los beneficios originales percibidos.

En lugar de poder introducir cambios rápidamente y a menor costo, podrías dedicar el mismo tiempo y recursos a coordinar múltiples proveedores de sistemas y pagar tarifas a proveedores de servicios fragmentados. Esto es especialmente cierto cuando considera el costo total de propiedad de una solución durante su vida útil.

Recuerda que ninguna tecnología garantiza el éxito. El equipo y su colaboración hacen o deshacen la implementación de su proyecto. Esto es cierto para esfuerzos pequeños y grandes, pero las probabilidades de éxito tienden a disminuir a medida que se introducen más personas y tecnologías. Un enfoque muy exitoso para un equipo de cinco puede producir resultados opuestos cuando el tamaño de su equipo es de treinta.

Si deseas obtener más información sobre las soluciones Headless CMS, o si actualmente se encuentra en medio de un proyecto de evaluación, ¿por qué no solicitas una demostración con nuestros expertos en experiencia digital o para analizar tus requisitos para una transformación digital exitosa en tu empresa?