IBM WebSphere Portal (rutas /wps/)

Por qué entonces

A principios de los 2000 la palabra que lo ordenaba todo era 'portal': un único punto de entrada donde cada departamento publicaba su parcela sin pisar a los demás, con permisos por área, identificación única y componentes reutilizables llamados portlets, que además eran un estándar aprobado (JSR-168, luego JSR-286). Para una administración grande que tenía que unificar la presencia de muchos organismos, encajaba con el problema real. Y venía de IBM, lo que en contratación pública significaba soporte, respaldo y un pliego fácil de defender.

Qué pasó

El modelo de portal se desinfló. Los portlets nunca fueron realmente portables entre productos, la personalización era rígida, y todo el peso de la interfaz se generaba en el servidor justo cuando la web se movía hacia el navegador. La industria se fue a gestores de contenido más ligeros con el front separado. IBM acabó vendiendo su división de software a HCL en 2019.

Por qué está mal hoy

Un WebSphere Portal en producción hoy es un producto propietario, caro de licenciar y de mantener, con muy pocos perfiles disponibles en el mercado que sepan tocarlo. Las URL delatan el producto y a menudo la versión, y arrastra por debajo una pila Java —servidor de aplicaciones, JDK, librerías— que se actualiza en bloque o no se actualiza.

En lo público

Es la arquitectura de la primera oleada seria de administración electrónica, la de 2005-2010: se compró con la idea de que duraría décadas, y en cierto modo acertaron. El problema no es que funcione mal, es que la organización queda atada a un producto que el propio fabricante ha dejado de empujar, con un coste de salida que crece cada año que pasa.

El arreglo

Migración a un gestor de contenidos actual con el front separado. Es un proyecto grande y caro; lo realista es hacerlo por secciones y empezar por las que tienen menos lógica de negocio detrás.