De acuerdo con Forrester, la mayoría de las organizaciones tienen más de un repositorio de contenidos y un número significativo de ellas tienen más de siete almacenes de contenidos. Hay una explicación natural para este hecho.
A menudo los contenidos están segmentados en función de su categoría: los contenidos multimedia se almacenan en sistemas de almacenamiento de multimedia, los documentos en Sistemas de Gestión Documental y los contenidos Web en sistemas de Web Content Management. A pesar de los numerosos intentos por lograrlo, nosotros como industria hemos fracasado en la creación de un Sistema de Gestión de Contenidos único que tenga la capacidad de gestionar igualmente bien los diferentes tipos de contenidos.
Además, los contenidos suelen estar segmentados por departamento o unidad de negocio. El departamento legal suele utilizar un sistema de gestión de contenidos diferente del sistema utilizado por el departamento de marketing, y en las empresas que se han desarrollado a partir de adquisiciones de otras, es frecuente encontrar diferentes repositorios de contenidos entre las compañías que solían ser compañías independientes.
Por supuesto es posible intentar consolidar todo el contenido en un super-mega repositorio, pero las consolidaciones de contenido rara vez funcionan. En primer lugar está el problema de encontrar un sistema capaz de manejar los distintos tipos de contenidos igualmente bien. En segundo lugar, suele suceder que en el momento en el que se acaba el proyecto de migración, la empresa acaba de realizar una nueva fusión y un nuevo conjunto de repositorios de contenidos se tienen que consolidar.
Todo parece indicar que no tendremos más remedio que contemplar con tristeza siglos de fragmentación de contenidos.
Pero la fragmentación de contenidos es un proceso que conlleva muchos problemas. Si la información crítica de negocio está dispersa en numerosos repositorios, puede ser difícil implementar en toda la empresa procesos corporativos, políticas globales de seguridad y asegurar la conformidad con las regulaciones industriales y gubernamentales.
La fragmentación de contenidos puede afectar también negativamente la velocidad general del negocio. Si un miembro del equipo de ventas no puede acceder fácilmente a los modelos de contrato del repositorio legal, a las descripciones de producto o a las demos del producto en el directorio de preventa, la totalidad del proceso de venta resulta muy lenta y costosa.
Obviamente, para el problema de la fragmentación de los contenidos empresariales necesitamos una solución que nos permita gestionar, buscar y compartir con seguridad la información empresarial independientemente de donde esté almacenada.
El estado de la cuestión
Cuando se le pregunta a un conocedor de la industria de Gestión de Contenidos por una solución para un problema grave de fragmentación de contenidos probablemente se escucharan términos como “Conectores”, “JSR-170”, y “JSR-283”. Esos son los remedios al uso: los argumentos a su favor son bonitos y bastante jugosos, especialmente para los seguidores de Java, pero la cruda verdad es que se trata de píldoras difíciles de tragar.
La situación es la siguiente: probablemente el Sistema de Gestión de Contenidos o las aplicaciones de negocio están alojadas en un Servidor de Aplicaciones Java, así que lo único que se necesita es conectar todos los repositorios de contenido dispersos por la empresa a dicho Servidor de Aplicaciones. Facilísimo: se cogen los maravillosos Conectores JSR-170 y se ponen en el Servidor de Aplicaciones. Aparentemente, hay conectores disponibles para muchos tipos de repositorios que se pueden utilizar para comunicarse con los distintos almacenes de contenidos desde las aplicaciones y sistemas de procesos de negocio desplegadas en la misma máquina. ¡Hecho!
Pero en realidad la carrera tiene algunos sobresaltos. En primer lugar, el arquitecto de sistemas se da cuenta de que el mundo no solo está hecho de Java. También existe esa pequeña empresa con un producto llamado SharePoint que no es precisamente un fan de Java, y tendrá mucha suerte si encuentra un conector JSR-170 que funciona con sus productos. En segundo lugar, después de encontrar o desarrollar los conectores que necesita, el arquitecto de sitemas descubre que aunque haya evitado la necesidad de consolidar contenidos, apenas ha acabado de consolidar los mecanismos de control y los flujos datos y ya empieza a pensar que el agujero que se abre ante él es aún más profundo.
La consolidación de los mecanismos de control y los flujos de datos implica que todas las peticiones para recuperar o procesar contenido fluyen a través de un eje central: el Servidor de Aplicaciones. Los usuarios empiezan a quejarse del rendimiento y aunque se pone más hardware, la situación no solo no mejora, sino que cada vez funciona peor.
¿ Por qué? Pues porque cada vez que se manda una petición al Servidor de Aplicaciones para encontrar una pieza de contenido que se necesita, éste usa los maravillosos Conectores JSR-170 para comunicarse con los repositorios de contenidos distribuidos, procesa los resultados brutos devueltos por esos sistemas, y sólo entonces produce la respuesta que puede ser enviada a los usuarios. Los haces luminosos viajan millones de veces en el nuevo sistema de fibra óptica entre los distintos sistemas antes de que le llegue alguna información útil al señor que está sentado en frente del monitor de su ordenador, que no está precisamente contento.
¿Pero qué puede hacer un infeliz arquitecto de sistemas ante esta situación? No tiene más remedio que aprender de los niños.
Aprendiendo de los niños
Puede resultar o no sorprendente, pero los niños, grandes amantes de los juegos y la música, ya han resuelto el problema de la fragmentación de contenidos sin que les haya causado grandes sudores.
¿Qué es lo que hace una niña cuando necesita un nuevo juego? Pues va a un lugar llamado el “torrent tracker”. Un torrent tracker es un directorio online que enumera todos los contenidos almacenados en cientos de miles de repositorios de contenidos y además permite realizar búsquedas super efectivas y recuperación de contenidos peer-to-peer. Normalmente no se emplea más de un segundo en encontrar una pieza de contenido y unos pocos minutos para descargarla.
Sí, ya sabemos que los torrents son “el mismísimo demonio” para la industria discográfica, pero no tenemos por qué condenarlos necesariamente sin aprender de ellos. Y lo cierto es que podemos aprender bastantes cosas.
La primera lección es que mientras que consolidar contenido no es una buena idea, consolidar algunos meta-data que describan el contenido es sin embargo muy útil. Un índice consolidado proporciona búsquedas super-rápidas como cualquier niño amante de los torrents confirmará.
En un entorno empresarial, podemos subir los índices al siguiente nivel. Podemos enriquecerlos con meta información relevante para el negocio extraída de los distintos sistemas y mapeada en un esquema común, y también podemos almacenar versiones en baja resolución de los videos y audios destinados a su pre-visualización. Hay muchas cosas que se pueden hacer mediante un índice consolidado y Google es la prueba viviente de esta afirmación.
Sin embargo, los índices en sí mismos no son suficientes. Una vez que hemos encontrado un elemento de contenido, necesitamos recuperarlo y modificarlo. Google se apoya en la ubicuidad del protocolo HTTP para lograrlo. Una vez que encuentras la página que necesitas, la puedes recuperar mediante HTTP y verla en tu navegador. Los Torrents por su parte se apoyan en el protocolo BitTorrent. Una vez que has encontrado el juego o la película que necesitas la puedes descargar usando ese protocolo. Se necesita un protocolo equivalente que se pueda utilizar para comunicar los distintos repositorios de la empresa.
En resumen, además de un índice de meta información consolidado, necesitamos un protocolo que se utilice para direccionar, recuperar y manipular cada pieza de contenido almacenada en la empresa. Un tal protocolo debe ser fácil de implementar en un repositorio de contenidos, y debe ser adecuado para las redes de hoy en día, sean estas lentas, rápidas, con conexión intermitente, fijas ó móviles.
Es un objetivo ambicioso, pero podemos ver signos ilusionantes en la industria. Flickr, el inmensamente popular servicio de fotografías online, es también un inmenso repositorio de imágenes. Los contenidos que ofrece son usados en numerosos web sites y por numerosas aplicaciones que acceden a ellos a través de http utilizando REST – conocido como el “RESTful protocol” –en español: “El protocolo relajante”.
A juzgar por el número creciente de aplicaciones que usan Flickr, este protocolo funciona increíblemente bien. Estas aplicaciones, por cierto, se llaman mashups y se utilizan para mezclar contenidos de Flickr con otros tipos de contenidos que puedan estar disponibles en otro web Site o en otra aplicación.
Algo así sería el esbozo de una solución completa de Integración de Contenidos Empresariales. Tal solución consistiría en un índice de meta-información centralizado que apuntase a montones de contenidos almacenados en montones de repositorios de contenidos que implementarían a su vez un API similar a la de Flickr para ofrecer manipulaciones y búsquedas seguras sobre los mismos.
Tanto el índice como el API se podrían usar por montones de mashups de contenidos empresariales creados a medida y accedidos on-line por cada equipo o departamento de la empresa.
…Algunos de nosotros hemos emprendido ya el camino para alcanzar esta visión.
