Sentimientos encontrados: Documentum (Parte II)

Por Omar Morales

Este texto no pretende relatar los distinto hitos en la existencia de Documentum, solo aquellos con los que tuve contacto directo y mi opinión al respecto, ¿crees que la historia fue diferente para ti?, comparte tu versión en los comentarios.

En esta ocasión escribo acerca de dos productos de Documentum que tuvieron evoluciones diferentes, uno tuvo que rehacerse después de pasar por dos licenciamientos OEM y el otro fue una adquisición que nunca terminó de «integrarse».

Una de las características que más ayuda a los usuarios de plataformas de Administración de Documentos Electrónicos es la búsqueda por contenido: esa capacidad de ubicar dentro de un documento, una hoja de cálculo, una presentación o un simple archivo de texto una palabra o frase particular. En los primeros proyectos en que participé esta funcionalidad no se utilizó, debido a que los archivos que se administraban eran imágenes TIFF o archivos PDF con imagen, después supe que era parte del Content Server de manera nativa. Esta funcionalidad le dio un par de dolores de cabeza a Documentum interesantes: el primero fue cuando el motor interno que se utilizaba, Verity, pasó a propiedad de Autonomy (quien después fue adquirida por HP) y entonces el acceso al licenciamiento OEM se detuvo/deterioro/¿canceló? provocando que nuevos formatos que debieran indexarse no se agregaran. Para solucionar este problema Documentum cambió el motor interno por Fastsearch en la versión 5.3, lamentablemente poco duró el gusto: Microsoft compró a Fastsearch en 2008, y anunció que no extendería los contratos OEM. Ante este contratiempo, Documentum inició el desarrollo del producto xPlore; que en mi opinión, fue una de las mejores creaciones de la compañía. Basada en las  librerías opensource Lucene y la base de datos xHive (que fue una de las adquisiciones de EMC del 2007), este producto es flexible, escalable y bastante fácil de configurar. Una de las ventajas que tiene es que el esquema de seguridad se replica del repositorio, así los resultados de las búsquedas ya están filtrados de acuerdo a los permisos asignados a los documentos, por lo que no hay necesidad de procesamiento adicional. Por la arquitectura independiente es fácil  conectarse a otros repositorios o plataformas para indexar y atender búsquedas, como ApplicationXtender; no dudo que OpenText haga uso de esta capacidad para integrarlo con otros productos, aunque lo haga con otro nombre.

Un producto que siempre llevó una vida paralela, casi subterránea, dentro de Documentum fue eRoom. eRoom es una espacio colaborativo para la administración de proyectos muy fácil de usar y relativamente fácil de administrar desarrollado inicialmente en una arquitectura IIS-Windows-ASP, un mundo opuesto al J2EE de los módulos Web de Documentum. Desde su adquisición en 2002, eRoom convivió/compitió con al menos dos productos: iTeam y CenterStage. iTeam tenía al menos dos años en el mercado cuando eRoom se incorporó a la compañía, pero su funcionalidad era muy limitada comparada con éste; eRoom fue por mucho tiempo uno de los productos líderes en el mercado, prueba de ello es que en el 2005 la versión 7.2 obtuvo el premio a el mejor software colaborativo en el evento anual del AIIM, los distintos clientes lo reconocían y estaban al pendiente de su crecimiento dentro de Documentum.

Documentum por su parte tenía otros planes: en primer lugar trató de integrar eRoom con el Content Server para centralizar la administración de los documentos en una plataforma y dejar la funcionalidad colaborativa en la otra, el problema fue que, siendo productos en plataformas diferentes la integración dejó mucho que desear, además de que requería labores administrativas en una y otra. Entonces inició el desarrollo de una plataforma equivalente a eRoom sobre J2EE a la que llamó CenterStage, en su momento Documentum lo promocionó como la plataforma Web 2.0 de administración de contenido; este producto estaba totalmente integrado con el Content Server y tenía una interfaz más amigable (o menos repudiable) que Webtop. La labor de venta de este no fue sencilla, recuerdo claramente dos clientes cuya primera pregunta era: ¿tiene gráfico de Gantt para los planes de proyecto?, la respuesta era: no aún, pero está en desarrollo; entonces los clientes decían: regresen cuando lo tenga. Nunca regresamos, porque nunca lo tuvo.

La realidad le ganó la carrera a Documentum por volumen, en algo que seguramente sucede en empresas que usan Sharepoint hoy en día, eRoom es tan sencillo de usar que los usuarios creaban carpetas, subían documentos, creaban conversaciones, creaban «bases de datos», agregaban planes de proyectos, creaban notas y encuestas en grandes cantidades, tanto que en una entidad de gobierno llegaron crecer hasta ocupar cientos de gigabytes; Documentum no tuvo más remedio que detener el desarrollo de CenterStage y continuar el soporte de eRoom.

La última versión de la que tengo conocimiento que se liberó de eRoom fue la 7.5 en 2015, su soporte termina en 2019 y el soporte extendido en 2022, cuando OpenText anunció la compra de la división de Enterprise Content Division no se hizo mención del producto, tampoco en el Webinar de enero de 2018 donde se presentaron los planes y lanzamientos relacionados con Documentum. ¿Es el destino de eRoom desaparecer? Podría ser, aunque hoy en día hay aún muchos usuarios de esta plataforma y varios de ellos no son menores.  La ONU tiene un eRoom versión 7.4.4 funcionando y  no creo que sea pequeña; otras organizaciones existen con sitios similares (msc y nedarcssl) y si bien una búsqueda en Google nos arroja varias herramientas para migrar sitios de eRoom a Sharepoint, no es una tarea menor. Sería interesante saber qué planes tiene OpenText para eRoom; tal vez alguien le hagan una oferta interesante y resurja de sus cenizas para tomar el lugar que alguna vez tuvo por encima de Sharepoint. O tal vez OpenText genere una estrategia comercial de sustitución por KineMatik, el cual afortunadamente si tiene gráfico de Gantt.

Sentimientos encontrados: Documentum (Parte I)

Por Omar Morales

Este texto no pretende relatar los distinto hitos en la existencia de Documentum, solo aquellos con los que tuve contacto directo y mi opinión al respecto, ¿crees que la historia fue diferente para ti?, comparte tu versión en los comentarios.

Hace 18 años participé en mi primer proyecto de ECM, que también fue el primero con Documentum, y la casualidad (o tal vez sea parte de la historia) me ha traído de vuelta a la misma institución, la misma área y la misma plataforma este año. Mucho podría escribir acerca de esta institución, pero ese no es el objetivo de este texto, lo que voy relatar hoy son los cambios que he visto en Documentum en estos 18 años.

En aquel marzo de 2000 Documentum era un sistema de administración de documentos electrónicos con una plataforma web básica llamada RightSite, un cliente web basado en Javascript llamado IntranetClient, un cliente de escritorio llamado Desktop y una suite enfocada al cumplimiento de legislación llamada Documentum Compliance Manager. A modo de referencia estos datos: Ernesto Zedillo aún era presidente de México, U2 aún no publicaba su último gran album “All that you can leave behind” y Blackberry con sus equipos monocromáticos dominaba el mercado de los smartphones.

Para alguien que venía de la administración de Novell Netware y su suite de correo Groupwise, así como para muchas personas que he conocido en estos 18 años, la administración de documentos electrónicos parecía una tarea menor y con poca utilidad en ese momento; sin embargo varias cosas en Documentum me parecieron interesantes, como la orientación a clasificar los documentos como objetos con clases y subclases, cada una con sus propiedades particulares, la capacidad de realizar consultas administrativas con sentencias SQL, los flujos de trabajo y los ciclos de vida, entre otras cosas. El objetivo de aquel proyecto, en aquel entonces y ahora, es la conversión de papel en documentos electrónicos por medio de la digitalización en escáneres de alto volumen, ese proceso también despertó mi interés: la forma en que debían prepararse los papeles, el ajuste que podía hacerse en la calidad de las imágenes, el reconocimiento óptico de caracteres, la captura de datos a partir de este reconocimiento, la operación de todo el proceso como tal de una línea de producción.

Durante el año que estuve en ese proyecto me quedó claro que ECM y Documentum eran una estrategia y un producto con mucho potencial, tanto que decidí seguir mi carrera tras ambos. Mis dos siguientes proyectos y varias horas destinadas a la preventa/demostración/evangelización fueron con Documentum; uno de ellos fue particularmente interesante porque fue de Web Content Management (WCM). En ese momento Documentum empezó a promover la visión de ECM como la administración de todo el contenido de una organización y la creación del mismo por medio del uso de XML, una visión avanzada y ambiciosa para la época. El paso de ser una plataforma de administración de documentos electrónicos a una plataforma de ECM tuvo que venir con la necesaria evolución de la plataforma Web de Javascript a J2EE y con la presentación de productos clave como WebPublisher y Site Caching Services, así como la capacidad de “ejecutar aplicaciones XML” (descomponer el archivo XML en varias partes y tomar información de ellas para capturar los metadatos) en archivos XML agregados al repositorio. El proyecto en el que participé buscaba administrar el contenido publicado al portal y a la intranet de una institución financiera, el proceso de administrar el contenido publicado al portal tuvo problemas de menores a complicados, pero salió adelante; la administración de la intranet fue otra cosa: la institución requería no sólo la administración del contenido, también la administración del portal como tal. El enfoque WCM de Documetum consistía en presentar una interfaz básica de captura a los usuarios finales y dejar que la combinación de XML y XSL generará la o las presentaciones necesarias: sitio Web, portal, sitio móvil, etc; después estas presentaciones se llevarían a los sitios Web por medio de los servicios de publicación (SCS). Este enfoque en un mundo en el que se ocupe HTML5 sería ideal, lamentablemente en esos días Flash era el rey, todas las empresas querían movimiento e interacción, además de que administrar contenido que debía presentarse en portales J2EE era relativamente fácil y, en otras herramientas, era posible controlar, monitorear y configurar, además del contenido que se publicaba, cosas tan básicas como una una encuesta en la página principal, administrar el acceso al portal o conocer la cantidad de usuarios y el contenido que consultaban. Algunas integraciones se dieron para completar esa funcionalidad requerida en los portales y sitios Web, pero no fueron suficientes para lograr la estabilidad y madurez de esa línea de productos. No participé en otro proyecto de WCM con Documentum, en octubre de 2015 Documentum, entonces ya parte de EMC, dio por terminado el soporte de WebPublisher, fue un final triste, pero no tanto como lo fue para el producto equivalente de Filenet, del cual también escribiré en un futuro.

Esta visión de controlar todo el contenido de una empresa en una sola plataforma por parte de EMC Documentum trajo al mercado la suite de productos llamada Media Asset Management (MAM), encabezada por el cliente Digital Asset Management (DAM); en un proyecto para una empresa de medios participé en la implementación de esta para facilitar el proceso de postproducción al integrar en un solo repositorio los documentos y videos transcodificados a baja resolución; la idea fue buena y sirvió como puerta de entrada a otros proyectos en aquella empresa, pero nos enfrentamos con una queja común, no solo a Documentum, sino a varias plataformas: la interfaz de usuario es horrible, no quiere decir que no sea funcional o que no sea rápida (que esto depende de otros factores), la queja era la distribución de los elementos, la combinación de colores y, particularmente para DAM, la “estética”. En este caso es importante señalar que la mayoría de los usuarios de esta suite de productos son personas con formación y experiencia en artes visuales, diseño gráfico, mercadotecnia, y pues están acostumbrados a interfaces estilo Mac, Adobe o Avid. DAM mejoró realmente hasta la versión 6.5 esta situación, cambiando la forma en que se presentaban las imágenes y los videos, así como la funcionalidad disponible para su modificación; lamentablemente no siguió la evolución, esa fue la última versión de esa interfaz y en este año termina su soporte. Hoy en día un partner de OpenText ofrece un cliente DAM basado en D2, el resto de los módulos de MAM los continúa desarrollando OpenText. Por el momento.