El Content As A Service —Contenido como Servicio— es un concepto con una mirada diferente a la gestión de contenidos. Los CMS tradicionales —como WordPress y Drupal— intentan ser la única solución para administrar contenido como para crear sitios web. Por su parte los proveedores de CaaS se centran exclusivamente en la administración del contenido.
En este artículo quiero abordar el concepto del Content As A Service. Y lo que puede implicar como nuevo paradigma en la gestión de contenido.
¿Qué es el Content As A Service o Contenido como Servicio?
Es un modelo orientado a servicios. Donde el proveedor de dicho servicio entrega el contenido bajo demanda al consumidor a través de servicios web. Que tienen licencia bajo suscripción. El proveedor de servicios aloja el contenido centralmente en la nube. Y se lo ofrece al número de consumidores que necesitan el contenido entregado en cualquier aplicación o sistema. Por lo tanto, el contenido puede ser demandado cuando sea necesario.
En una primera aproximación al concepto, podemos enumerar los tres principales actores que juegan en una arquitectura CaaS:
- La fuente,
- la nueva arquitectura de gestión de contenidos
- y el receptor de los contenidos.
En relación a la fuente. El origen de los contenidos puede ser muy amplio: un usuario o redactor, un proceso de negocio u otros gestores de contenidos. En el caso que queramos aglutinar diversos repositorios en uno solo.
En el modelo. El Content As A Service (CaaS) es el objeto principal y núcleo de toda la solución. Tendría como función recibir, almacenar y mostrar los contenidos. Algunos autores también incluyen entre las funciones de un «CaaS» la gestión de acceso a la información, la facturación en el caso de contenidos de pago y la personalización. Pero siendo puristas todas esas funciones se pueden llevar a cabo por módulos específicos. Como es el caso de los API managers, módulos de pricing & billing o módulos de personalización, respectivamente.
Sobre los contenidos en el modelo de CaaS
En este modelo, los contenidos pueden ser consumidos por una amplia variedad de dispositivos. Desde un teléfono móvil hasta un display en un aeropuerto, un cajero automático, una impresora, un SmartTV. Y con el Internet de las Cosas (IoT) hasta una nevera. De igual forma el consumo de contenido puede darse en un amplio número de canales: sitios web, aplicaciones móviles (híbridas o nativas) o redes sociales. Dicha sea la verdad. Cualquier sistema puede ser un potencial consumidor de contenidos, no sólo un canal, también, por ejemplo, una herramienta de BI u otro Gestor de Contenidos.
Para la integración con los otros actores de la arquitectura. Un CaaS publica un conjunto de APIs que permiten crear y consumir contenidos. E intercambia la información utilizando cualquiera de los formatos estructurados más extendidos: XML, o más frecuentemente, JSON.
Diferencias entre CaaS y WordPress / Drupal / otro CMS web
Contenido estructurado:
Estos CMS alientan a los propietarios de contenido a estructurar su contenido, para que operen en fragmentos, no en bloques de páginas. Esto refleja el cambio de la web centrada «en la página» a la web centrada «en el contenido». La pieza WYSIWTF del experto en estrategia de contenido Karen McGrane ofrece un contexto excelente de por qué los trozos son mucho mejores que los blobs.
Enfoque desacoplado:
El Content As A Service siempre implica separar el front-end (la presentación del contenido) del back-end (almacenamiento y entrega de contenido). Esencialmente, esta separación de preocupaciones simplifica la arquitectura del CMS: cada pieza hace su propia cosa. Lea más acerca de CMS sin cabeza / desacoplado.
Separación de contenido y presentación:
Esta familia de CMS ya no impone limitaciones de diseño en el producto. Significa que un CMS solo se usa para administrar y entregar contenido puro. Y el cliente específico del canal decide acerca de cómo lo mostrará de forma visual.
Configuración en la nube:
CaaS, como un subgrupo del enfoque de SaaS (software como servicio), mueve el contenido de sus servidores a la nube del proveedor. Eso significa que cada usuario de CaaS no tiene que configurar, mantener y escalar la infraestructura por su cuenta, el proveedor hace eso para cada uno de ellos.
Casos de uso para el CaaS
Siempre digo que no hay una solución mágica: no existe un CMS único que sea igual de bueno para un blog personal como para una tienda en línea. Sin embargo, el Content As A Service supera a sus predecesores en algunos casos de uso como:
- Contenido de aplicaciones móviles back-end. Tener contenido en una aplicación móvil desde un CMS CaaS es la mejor manera de poseer contenido dinámico en la aplicación sin tener que volver a enviar la aplicación al mercado de aplicaciones. Además, usar una solución existente como backend es más inteligente que construir uno propio (según los chicos de contentful).
- Publicación multicanal. CaaS CMS también es muy gratificante cuando el contenido debe reutilizarse en diferentes plataformas: por ejemplo, deseas enviar el mismo contenido a un sitio web y a aplicaciones móviles.
- Aplicaciones web enriquecidas. Los marcos frontales de MVC modernos, como AngularJS, React y Ember, funcionan muy bien con contenido estructurado a través de una API.
Integración con servicios existentes y pilas de software. Existen contextos en los que un CMS podría ayudar a simplificar los flujos de trabajo en un proyecto existente: por ejemplo, eliminando el contenido codificado de las páginas HTML y manteniéndolo con un CMS en su lugar. Como CaaS CMS proporciona una API, todos son muy amigables con la integración. - UX altamente personalizado. El CMS de la era web impuso fuertes restricciones de diseño. Sí, puedes personalizar completamente la Interfaz de Usuario (IU), pero construir una aplicación web utilizando WordPress desde cero es poco probable. Como el trabajo de CaaS es simplemente impulsar el contenido donde y cuando sea necesario, los diseñadores estarán felices de no escuchar «imposible» de sus compañeros desarrolladores.
- Creación de contenido programático. Cuando el contenido ya existe y proviene de múltiples fuentes, la carga de contenido en un repositorio unificado es ideal para crear contenido a través de la API también.
Pros y contras
Si el CaaS es tan bueno, ¿por qué no todos lo están usando ya? Bueno, sobre todo porque es bueno en algunos contextos (ver la sección anterior) y no tan espléndido en otros.
Por ejemplo, no es tan bueno para configurar un blog personal. O no es tan bueno cuando sabes que solo quieres hacer un sitio web, y eso es todo. Porque el esfuerzo no vale la pena: hay otras soluciones, mucho más baratas y menos complicadas, para estos escenarios particulares.
La adopción del modelo del Content As A Service la iremos viendo paulatinamente. En la medida en que los desarrolladores de aplicaciones móviles necesiten una solución más robusta en el backend. Y por otro lado, mientras más generadores de contenido requieran distribuir mejor (y con relativo menor costo) en plataformas muy diversas.
Digital Marketing Manager en Orienteed. Consultor en Estrategias de Inbound Marketing y Comunicación Digital. Diseñador Web, especializado en Usabilidad y UXp. Coach Ontológico Profesional certificado. Director de Mauna Media.