‘Todo como servicio’ no incluye todos los servicios que brinda TI, sin mencionar todo lo que está fuera de TI que se puede caracterizar como un servicio. Y lo que omite es posiblemente más importante que lo que incluye.

Lamentablemente, XaaS se define como “cualquier servicio informático que se entrega a través de Internet y se paga en un modelo de consumo flexible en lugar de una compra o licencia inicial”.

Si usted busca un poco en Google acerca de XaaS, encontrará mucha efusión repetitiva, pero para los más icónicos entre nosotros, es difícil evitar concluir que XaaS es, de hecho, poco más que la intersección de la computación basada en la nube y los contracargos .

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 para los no iniciados podrían considerar como el conjunto más importante de servicios que brinda TI, es decir, todo lo que los analistas de negocios, los consultores internos de TI y el personal de soporte y desarrollo de aplicaciones hacen para ganarse la vida.

Lo que supongo que significa que “Todo” como servicio es realmente “Algunas cosas como servicio” (AFTaaS), o tal vez “Todo excepto el esfuerzo como servicio” (EEEaaS).

Lo que XaaS realmente debería significar

A lo que XaaS debería referirse es a la aplicación lógica de los principios de SOA a casi todo lo que se hace en la empresa.

Debería, por ejemplo, incluir lo que las empresas de servicios denominan externalización de procesos empresariales (BPO). También puede incluir lo que podríamos denominar “internalización de procesos comerciales”, pero que generalmente llamamos “servicios compartidos”.

Trabajo como servicio (WaaS), ¿sería más correcto así?

A lo que voy es que XaaS debe incluir no sólo la tecnología en sí, sino también los resultados comerciales que respalda la tecnología.

Pero no quién paga, y cómo. La arquitectura se trata de cómo se combinan las soluciones, no de cómo se financian.

‘Work as a Service’: Servicios compartidos como arquitectura

Es bien sabido que BPO no es nuevo, y ha hecho que pagar por el trabajo realizado sea una opción desde su creación.

Y así como el área de TI puede proporcionar SaaS a sus usuarios comerciales, ya sea mediante la nube comercial o por aplicaciones provistas internamente, las funciones comerciales pueden hacer que sus servicios estén disponibles para el resto de la empresa organizándose como servicios compartidos provistos internamente, o bien, mediante un proveedor de BPO.

Pero un grupo de servicios compartidos no es sólo como un BPO interno. ¿Cuál es la diferencia entre ellos? Que contratar a un proveedor de BPO no es una decisión arquitectónica. La organización como un servicio compartido interno seguramente sí lo es.

La decisión de contratar a un proveedor de BPO suele ser una admisión de falla de gestión. Transfiere la responsabilidad de una función comercial que la administración interna no pudo supervisar adecuadamente en un contrato.

Sin embargo, esto no siempre significa que la organización como una colección de servicios compartidos sea la opción correcta.

Entre las desventajas podremos encontrar las siguientes: una arquitectura comercial interna de servicios compartidos, a diferencia de un BPO, tiene, cuando se lleva a su conclusión lógica, un resultado reductio ad absurdum , donde cada departamento comercial cobra a todos los demás departamentos comerciales por los servicios que brinda. Por ejemplo, TI podría cobrarle a Recursos Humanos (RRHH) una tarifa mensual por el uso del HRIS, mientras que RRHH podría corresponder cobrando a TI por los servicios de contratación, administración de beneficios y nómina.

Los servicios compartidos ubicuos pueden convertir a la empresa en un gigantesco uróboro financiero (uróboro = figura de serpiente circular que se muerde la cola, N. del E.).

Arquitectura orientada a servicios empresariales: una talla única que no le queda a nadie

Los BPO y XaaS comparten una característica que podría, en algunas situaciones, ser un beneficio, pero en la mayoría de los casos es una limitación, por ejemplo, la necesidad de comercializar. Este requisito tampoco es una cuestión de preferencia de TI por la simplificación. Está impulsado por la preferencia de los responsables de la toma de decisiones de la arquitectura empresarial por estandarizar los procesos y las prácticas en todos los ámbitos.

Esto puede no parecer una elección onerosa, pero puede serlo. Brindar un servicio que funcione de la misma manera para todos los interesados, sin importar sus necesidades específicas y únicas, puede reducir los costos inmediatos pero, a la larga, puede ser paralizante.

“Estandarizar” es fácil de decir, pero difícil de hacer funcionar correctamente. 

En esto, lo que podríamos llamar una arquitectura orientada a los servicios empresariales, no es tan diferente de adoptar un SOA (junto con los microservicios, sus pequeños hermanos) para la arquitectura de su aplicación. En ambos casos, hacer cumplir la estandarización en una sola versión es ingeniería de “talla única”.

Bob Lewis, CIO.com