Plataformas de entrega de servicios para dummies

Francisco Javier Almellones  15 octubre, 2013

En un entorno tecnológico como el actual, donde la palabra cloud es lo que está de moda, se está abriendo hueco, en el ámbito técnico, una nueva filosofía para construir servicios “Cloud compliant” (compatibles cloud). Se trata de las plataformas de entrega de servicios o SDP según sus siglas en inglés: Service Delivery Platform.

Intentaré explicar en qué consiste una Service Delivery Platform con un ejemplo algo burdo: si queremos montar una churrería de toda la vida, simplificándolo mucho, necesitaremos al churrero, los ingredientes y los utensilios para  hacer los churros, una forma de hacer el pedido, un sitio donde servirlos y algún mecanismo para cobrar. En un negocio clásico todos ellos son elementos disjuntos que, si bien forman parte del mismo negocio, se montan y mantienen por separado.

Ahora bien, ¿qué pasaría si quisiéramos automatizar nuestra churrería tradicional y simplificar la vida al cliente hasta tal punto de que pudiera hacer pedidos a cualquier hora del día y recibir una única factura mensual por el importe de lo consumido?

Asumiremos un proceso previo: el alta del cliente, mediante el cual lo dotaremos, por ejemplo, de una tarjeta de fidelización que lo identifique y a la que asociaremos los datos de facturación del mismo (dirección, cuenta bancaria, etc.). Éste será nuestro “identificador de cliente”.

Imaginemos que podemos construir una máquina que automatice la realización de la masa, le dé forma y que sea capaz de freírla sin que se queme. Ya tenemos resuelto el núcleo (core) de nuestro negocio: la fabricación de churros. Ahora hay que darle la capa de “servicio”, esto es, automatizar al máximo el resto de tareas y procesos.

A esta máquina, a la que llamaremos churros-builder, podemos añadirle un método de entrada en el que, tras introducir nuestro identificador de cliente seleccionemos qué tipo de churros queremos y qué cantidad de cada uno. Así estaríamos automatizando la fase de pedido. Un software conectado con la churros-builder se encargará de validar al cliente y dar las órdenes pertinentes para que se fabrique el encargo. Con esto, dotaremos a nuestra moderna churrería de la capa de tramitación y aprovisionamiento del servicio.

Una vez listo nuestro pedido, existirá un lugar en el que, volviendo a identificarnos, podremos recogerlo. Y así cubrimos  la fase de entrega del servicio, a partir de la cual el cliente puede disfrutar de los productos solicitados.

Puesto que nuestro “engendro” conoce el identificador de los clientes, qué ha consumido cada uno y además tiene una fantástica memoria, haremos que guarde todos estos datos a buen recaudo. A final de mes, nuestra churros-builder, que es muy moderna y está conectada con nuestra oficina, enviará un listado de todos los clientes y cada uno de sus pedidos, con lo que ya tenemos el generador de consumos.

Dado que los precios pueden ir cambiando (ya sabéis: subidas de IVA, bajadas… ¡ah no, que bajadas no hay!), hemos decidido no guardarlos en la churros-builder y apuntarlos en nuestra oficina. Basta entonces con multiplicar cada cantidad consumida por su importe. A esto se le suele denominar “hacer el PxQ” o “Precio por Cantidad” (Price x Quantity), para obtener los importes finales que hay que facturar a cada cliente. Con esto casi se cierra el proceso de facturación o billing. Tan sólo nos queda enviar el resultado a algún sistema que nos construya unas bonitas facturas con nuestro logo de la Churros Builder 2.0, entregarlas a los clientes y que nuestro banco se encargue de cobrarles, pero esa es otra historia porque ¿quién quiere ahora hablar de pagar?

Para que realmente sea automático, es importante dotar a nuestro invento de algún mecanismo para realizar comprobaciones y asegurar que en cada fase ocurre lo que tiene que ocurrir (por ejemplo que aún nos queda masa, que los churros no se queman…) y, si no es así, tomar medidas. Hay que hacer que todo funcione como una orquesta, así que a este mecanismo de control lo llamaremos ¡tachán!: ¡el orquestador! (Orchestrator que dicen los anglosajones).

Pues bien, este engendro mecánico y tecnológico que acabamos de fabricar juntos es una Plataforma de Entrega de Servicio. Podemos coger los módulos, construir un bloque compacto y replicarlo en cada barrio de nuestra ciudad. Si bien hay una diferencia fundamental con este cómico ejemplo y el mundo TI: los churros son un producto propio de un proceso de manufactura, mientras que los servicios cloud no son algo tan físico y tangible.

Fijaos que si por ejemplo quisiéramos comercializar servidores virtuales en vez de churros, las fases implicadas (petición, entrega, facturación, etc.) básicamente son las mismas. Naturalmente cambian las formas y el medio, porque no vamos a ir a la esquina del barrio a pedir un servidor virtual, pero si adaptamos adecuadamente el modelo de nuestra churros-builder… ¡podríamos vender servidores como churros!

En un entorno tecnológico, los componentes necesarios son muchos más, por lo que también se complica la lógica, los flujos, los mecanismos de control y las integraciones necesarias entre dichos productos. Hasta no hace mucho tiempo, las plataformas se construían “a lo Frankenstein”, cogiendo una pieza de aquí y otra de allá. Cuantos más fabricantes y productos implicados, mayor complejidad para integrarlos y conseguir que se comuniquen entre sí. Sin embargo, la tendencia actual en el desarrollo de servicios “en la nube” es que los fabricantes entreguen una solución perfectamente orquestada y funcional, que incluya además tanto el hardware como el software y las herramientas para cubrir todos los procesos.

Podría sonar idílico, pero la realidad es algo distinta, porque al igual que una mesa con sillas no encaja igual de bien en todas las cocinas, también es necesario hacer adaptaciones para que estas plataformas encajen en los procesos propios y los sistemas ya existentes en cada operador de TI. Aun así, se reducen las necesidades de desarrollo para integrar productos, y esto tiene dos ventajas claras: reducción de los costes de despliegue y del tiempo de salida al mercado; ventajas que impactan directamente en el precio que el cliente paga por el servicio.

Así que, lejos de ser un camino de rosas, una vez elegido el proveedor y la plataforma adecuada (nada fácil, ya os lo adelanto) queda mucho trabajo todavía para conseguir que todo funcione “como la seda” y simplificar tanto la contratación y uso del servicio por parte del cliente como facilitar al operador de TI la gestión de todo el sistema.

 

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *