XaaS no lo es todo y tampoco sirve para todo

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

Si buscamos en Google sobre XaaS, encontraremos muchos comentarios repetitivos, pero para los más escépticos, es difícil evitar llegar a 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 contracargos.

Y sin embargo, en todo el debate, 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 proporciona 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 "Unas cuantas cosas como servicio" (AFTaaS), o quizás "Todo excepto el esfuerzo como servicio" (EEEaaS).

Lo que realmente debería significar '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": servicios compartidos como arquitectura.

La cuestión es la siguiente: el BPO no es nuevo, y ha hecho que pagar por el trabajo sea una opción desde sus inicios.

Y al igual que TI puede proporcionar SaaS a sus usuarios de negocio, ya sea a través de la nube comercial o de aplicaciones 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 del fracaso de la gestión. Se transfiere a un contrato la responsabilidad de una función empresarial que la dirección interna no podía supervisar adecuadamente.

Sin embargo, esto no siempre significa que organizarse 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 información de recursos humanos, mientras que RRHH podría cobrar a 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 ouróboro (serpiente que se devora a sí misma) 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; 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 todos los ámbitos.

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

Imaginemos, por ejemplo, que Recursos Humanos adopta el enfoque de la Arquitectura Orientada a Servicios Empresariales, ofreciendo Recursos Humanos como Servicio a sus clientes internos. Como parte de HRaaS, ofrece Recruiting as a Service (RaaS). Y para justificar esta transformación, ensalza las virtudes de la estandarización de procesos para reducir costes.

Imagínatee que eres el responsable de las operaciones de la tienda de un minorista muy estacional, que tiene que aumentar su personal en la tienda desde el Viernes Negro hasta el Día de San Esteban. Imagina también que el departamento de TI necesita contratar un DBA.

Confío en 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 esto, 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.