XaaS no lo es todo… y tampoco sirve para todo

Todo como servicio (XaaS) se define, lamentablemente, como "cualquier servicio informático que se suministra a través de Internet y se paga en un modelo de consumo flexible en lugar de una compra o licencia por adelantado".

Si se busca en Google sobre XaaS, se encontrarán muchos comentarios repetitivos, pero para los más escépticos es difícil evitar la conclusión de que XaaS es, de hecho, poco más que la intersección de la computación en la nube y los cobros.

Y, sin embargo, en toda la discusión, parece que se ha ignorado que XaaS es el resultado lógico de la arquitectura orientada a servicios (SOA).

También es extraño que XaaS excluya la parte de "todo" que los no iniciados podrían considerar como el conjunto más importante de servicios que presta la TI, es decir, todo lo que hacen para ganarse la vida los analistas de negocio, los consultores internos de TI y el personal de desarrollo y soporte de aplicaciones.

Lo que supongo que significa que "todo" como servicio es en realidad "algunas cosas como servicio" (AFTaaS), o quizás "todo excepto el esfuerzo como servicio" (EEEaaS).

Qué debería significar realmente ‘XaaS’

Lo que debería significar XaaS es la aplicación lógica de los principios SOA a casi todo lo que se hace en la empresa. Debería incluir, por ejemplo, lo que las empresas de servicios llaman externalización de procesos de negocio (BPO). También debería incluir lo que podríamos denominar "insourcing de procesos de negocio" pero que normalmente llamamos "servicios compartidos". ¿Alguien quiere hablar del trabajo como servicio (WaaS)?

XaaS debería incluir no sólo la tecnología en sí, sino también los resultados empresariales que la tecnología soporta. Pero no quién paga ni cómo. La arquitectura tiene que ver con el modo en que se arman las soluciones, no con su financiación.

El "trabajo como servicio": los servicios compartidos como arquitectura

La cuestión es que el BPO no es nuevo, y desde sus inicios ha permitido pagar por el trabajo.

Y al igual que TI puede proporcionar SaaS a sus usuarios de negocio, ya sea a través de aplicaciones comerciales en la nube o de provisión interna, las funciones de negocio pueden poner sus servicios a disposición del resto de la empresa mediante la organización de servicios compartidos de provisión interna, o mediante el uso de un proveedor de BPO.

Pero un grupo de servicios compartidos no es como un BPO sólo interno. ¿La diferencia entre ellos? La contratación de un proveedor de BPO no es una decisión arquitectónica. Organizarse como un servicio compartido interno sí lo es.

Al igual que la mayoría de las demás subcontrataciones, la decisión de contratar a un proveedor de BPO suele ser una admisión de fracaso de la gestión. Se transfiere a un contrato la responsabilidad de una función empresarial que la dirección interna no podría supervisar adecuadamente. Sin embargo, esto no siempre significa que la organización como un conjunto de servicios compartidos sea la opción correcta.

Entre las desventajas: una arquitectura empresarial de servicios compartidos interna, a diferencia de un BPO, tiene, cuando se lleva a su conclusión lógica, un resultado de reductio ad absurdum, en el que cada departamento empresarial cobra a todos los demás departamentos empresariales por los servicios que presta.

Por ejemplo, el departamento de TI podría cobrar a RRHH una cuota mensual por el uso del sistema de gestión de recursos humanos, mientras que RRHH podría corresponder cobrando al departamento de TI por los servicios de contratación, gestión de beneficios y nóminas. Los servicios compartidos omnipresentes pueden convertir a la empresa en un gigantesco conglomerado financiero.

Arquitectura orientada a los servicios empresariales: una talla única para nadie

Los BPO y los XaaS comparten una característica que, en algunas situaciones, podría ser una ventaja, pero que en la mayoría de los casos es una limitación, a saber, la necesidad de comoditización. Este requisito tampoco es una cuestión de preferencia de TI por la simplificación. Está impulsada por la preferencia de los responsables de la arquitectura empresarial por estandarizar los procesos y las prácticas en general.

Puede parecer que no es una opción onerosa, pero puede serlo. Ofrecer un servicio que funcione de la misma manera para todos los usuarios, independientemente de sus necesidades específicas y únicas, puede reducir los costes inmediatos, pero a largo plazo puede ser perjudicial.

Imaginemos, por ejemplo, que recursos humanos adopta el enfoque de la arquitectura orientada a los servicios empresariales, ofreciendo recursos humanos como servicio a sus clientes internos. Como parte de HRaaS, ofrece la contratación como servicio (RaaS). Y para justificar esta transformación, ensalza las virtudes de la estandarización de procesos para reducir costes.

Imagínese que usted es responsable de las operaciones de tienda de un minorista muy estacional, que tiene que aumentar su personal en la tienda desde el Black Friday hasta el Boxing Day. Imagina también que el departamento de TI necesita contratar un DBA.

Creo que está claro que el mismo proceso no funcionará tanto para la contratación de cientos de empleados en las tiendas como para la contratación de un único profesional técnico altamente especializado.

"Estandarizar" es fácil de decir, pero difícil de hacer que funcione bien. Y eso antes de que el director de RRHH responsable de la contratación intente explicar lo que necesita que haga el SIRH.

En este sentido, lo que podríamos llamar una arquitectura orientada a los servicios de negocio no es tan diferente de la adopción de SOA (junto con los microservicios, sus hermanos pequeños), para su arquitectura de aplicaciones. En ambos casos, imponer la estandarización en una única versión es una ingeniería de talla única.