Pasos hacia el Cloud de la mano de estándares internacionales: ISO 20000 e ISO 37500

Empezaremos por definir el concepto de Cloud según el NIST (Mell and Grance, 2012). "Cloud Computing es un modelo que permite el acceso ubicuo, conveniente y bajo demanda, a través de la red, a un conjunto compartido de recursos informáticos configurables (por ejemplo, redes, servidores, almacenamiento, aplicaciones y servicios) que pueden ser rápidamente aprovisionados y liberados con un esfuerzo mínimo de gestión o interacción con el proveedor de servicios. Este modelo de nube se compone de cinco características esenciales, tres modelos de servicio, y cuatro modelos de despliegue…”.

¿Migrar servicios al Cloud es una moda o una necesidad?. Esta cuestión podría dar lugar a debates de horas y horas, pero lo que no es cuestionable es que es una realidad, el Cloud ha venido para quedarse. Prueba de ello es que hemos incorporado a nuestra jerga un nuevo vocablo “El tenant”. Si habéis oído hablar de la nube seguramente habréis oído hablar de los “tenants”. Anglicismo que hemos incorporado a nuestra colección de palabras técnicas, relacionada con el concepto de “inquilino o huésped”. Hasta la fecha término que se utilizaba solo para referenciar un alquiler en un local y ahora hemos trasladado este concepto al alquiler de servicios en la nube.

Estrategias como la que se aprobó en 2012 por la comisión Europea han allanado el camino. Características como la facilidad de acceso multi-dispositivo y alta disponibilidad, flexibilidad en la entrega y aprovisionamiento de recursos, flexibilidad en las formas de pago/facturación y soporte 24x7 han sido percibidos como claros beneficios. Aunque según el informe de la ONTSI sobre los retos y oportunidades del Cloud computing, aún se perciben barreras que dificultan su penetración como: la complejidad de los proyectos de migración, dificultad de entendimiento de las ofertas, dependencia del proveedor, dificultad de migrar servicios con alto nivel de integración con otros servicios de la organización, alta dependencia de las comunicaciones en servicios SaaS…

Las organizaciones quieren emprender esta nueva andadura, pero la mayoría no tienen claro si implica romper con lo establecido o evolucionar adaptando modelos de gestión de servicios que ya tenemos. Ir de la mano de consultores expertos nos facilitará la labor.

Como palancas introduciré dos estándares internacionales que pueden ser de gran ayuda: ISP/IEC 37500 como estándar que nos guiará durante el proyecto de externalización, podemos ver los servicios Cloud como una evolución del outsourcing tradicional. Y la parte 9 norma ISO/IEC 20000 que nos facilitará una visión de cómo gestionar servicios en la nube.

Empezaremos por describir brevemente el estándar ISO/IEC 37500 y en qué nos puede ayudar.

Migrar servicios al Cloud no deja de ser un proyecto de externalizar servicios o parte de los mismos, según la modalidad de servicio que escojamos (SaaS, IaaS o PaaS). De modo que adicionalmente a los marcos tradicionales de gestión de proyectos como PMP o Prince2. El estándar refuerza aquellos aspectos que se deben tener en cuenta durante un proceso de esta índole destacando 4 grandes fases cíclicas:

Durante la fase de análisis y estrategia, será clave identificar los servicios a externalizar, es decir el alcance del proyecto. Los servicios que escojamos no deberían estar vinculados a procesos estratégicos de la organización en primera instancia, y deberían respaldar la estrategia organizacional facilitando mayor valor para el negocio tras la migración. Sería recomendable que tengan poca integración con el resto de servicios, pueden tener alta variabilidad en la demanda y elevados requisitos de Hw y Sw. Con este tipo de servicio es donde se podrá ver más rápidamente y fácilmente el ROI.

Desde el punto de vista del cliente, lo primero que tenemos que definir son las expectativas durante la fase de estrategia del proyecto. Pero para ello tiene que quedar claramente definido los servicios que nos ofertan, modalidades, sla’s…

Para ello tendremos que gestionar con el proveedor cuestiones relevantes como:

• La propiedad de los datos
• Los SLA’s
• Provisión on-demand self-service, que nivel nos van a proporcionar y cómo.
• Gestión de la continuidad, debe quedar por escrito los mecanismos que proporcione el Cloud para replicar el servicio en ubicaciones alternativas dentro del RPO establecido.
• Accesos para monitorizar los servicios y modelo reporting
• Gestión de accesos por perfiles sólo a personal autorizado, mecanismos de autenticación.
• Cómo incrementar el aporte de valor, en términos que ambas partes se sientan confortables y haya un total entendimiento de las mismas.

Para ello deberemos apoyarnos elaborando un Business Case que incluya el alcance, servicios potenciales, planificación a alto nivel, beneficios esperados en términos medibles, riesgos asociados, costes estimados y calidad del servicio…

Será más que recomendable elegir servicios que dispongan de acuerdos de nivel de servicios con informes de calidad y un modelo de costes por servicio, ya que nos permitirán disponer de una la línea base y comparar el antes vs después.

En la fase de iniciación deberemos escoger con qué proveedor o proveedores Cloud nos quedamos. Podemos utilizar la guía de evaluación de servicios Cloud del NIST, para ver los servicios ofertados por los proveedores. Y en qué medida facilitan el aprovisionamiento, son accesible desde Internet, permiten compartir recursos con varios clientes (modelos multi-tenants), escalar y liberar servicios rápidamente y medir el consumo cubriendo todas nuestras necesidades.

Adicionalmente en esta fase debe definirse el modelo de gestión de los servicios, los requisitos legales y regulatorios que deberán considerarse antes de negociar el acuerdo y definir el modelo de relación.

Las organizaciones que ya dispongan de un sistema de gestión de servicios basado en la norma ISO 20000 están de suerte, porque en la segunda parte del artículo veremos cómo nos servirá la parte 9 para gestionar servicios en la nube y acompañarnos en este proceso.

En la siguiente fase de transferencia se definirá el equipo del proyecto y se establecerán las responsabilidades mediante una matriz RACI. Adicionalmente se implementará el proceso de la gestión de la demanda y se adaptarán los procesos de la gestión del servicio. Validaremos el marco de entrega, se acordarán los KPI’s y se lanzará un piloto. Esta fase terminará con el formal sign-off que implicará la transferencia de responsabilidades al proveedor en función de la modalidad contratada y los requisitos contractuales acordados.

Finalmente, llegaremos a la fase de “aporte de valor” y no por ser la última es la menor importante. Sinceramente creo que es la que da sentido o justifica un proyecto de este tipo. Ya que debemos hacernos una reflexión “si solo migramos para mantener el statu quo” ¿realmente tiene sentido emprender el proyecto? Desde mi punto de vista el proveedor nos tiene que dar algo más, y no cualquier cosa sino aquello que nos permita aumentar el aporte de valor organizacional de los servicios desde el punto de vista de la utilidad y garantía, innovando y mejorando el servicio actual. Y como recomendación antes de “lanzarnos a la piscina tomemos precauciones”, de modo que será muy importante que incluyamos en el contrato el compromiso del proveedor a facilitarnos la información que necesitemos si rescindimos el mismo.

Hemos visto que durante el proyecto y tras la migración será fundamental gestionar adecuadamente los niveles de servicios, los consumos, analizar patrones de actividad para rentabilizar al máximo los contratos, gestionar los cambios, la disponibilidad y continuidad... Y para ello contar con un sistema de gestión de servicios certificado bajo la norma internacional ISO/IEC 20000 será de gran ayuda, ya que facilita procesos para cubrir dichas necesidades.

Pensar que este tipo de proyecto gira entorno al concepto de “servicio”, al final lo que migramos a la nube son servicios, de ahí que contar con una PMO integrada con una SMO (oficina de gestión de servicios) nos facilitará la labor, ver artículo: Gestión de proyectos y servicios ¿mundos paralelos?

La parte 9 de la norma ISO 20000 nos servirá de gran ayuda para gestionar servicios en el Cloud, aplica tanto a modelos de servicio SAAS, PAAS, IAAS cómo a los modelos de despliegue comunitario, privadas, públicas o híbridas.

Desde el punto de vista del proveedor gestionar servicios en el Cloud es sinónimo de altos ratios de cambios debido a la gestión on demand self-service, facilitar acceso desde cualquier ubicación y dispositivo, poder elegir si queremos un entorno reservado solo para nosotros o compartido (multitenant) y todo ello sin tener visibilidad end-to-end.

Sin una adecuada gestión, las expectativas del cliente pueden verse mermadas y no alcanzar mayor agilidad, flexibilidad, reducir costes o disponer de nuevas ventajas competitivas.

La adaptación de los procesos del sistema de gestión ISO 20000 debe realizarse en la fase de transición. Pensar que una vez el servicio de haya transferido, la gestión se convertirá en el “core” de los departamentos de TI y dichos procesos en las herramientas de apoyo. Siendo la gestión de sla’s, costes, seguridad, contratos y suministradores los procesos estrella.

La gestión de la seguridad también será una cuestión relevante, un análisis y gestión del riesgo será sin duda grandes aliados. Se recomienda que la política de seguridad se incluya en el acuerdo formal. Las transferencias internacionales de información será otro aspecto a tener en cuenta sin duda. Así como acordar un procedimiento con el proveedor para reportar incidentes críticos de seguridad y análisis forenses.

No podemos pensar que migrar servicios al Cloud no vaya afectar a la operación de dichos servicios, de modo que tendremos que adaptar los procesos de gestión de incidencias y peticiones incorporando en los flujos de escalado un nuevo elemento en la ecuación “el proveedor Cloud”. También será importante dejar claro con el proveedor que tipo de peticiones vamos a dejar que sean pre-autorizadas por el usuario.

Por último, destacaré que los procesos de gestión de cambios y entregas también tendremos que adaptarlos, así como la política. Para dejar muy claro los tipos de cambios que puede hacer unilateralmente el proveedor, los que deberá notificar y los que necesitará autorización del cliente.

Espero que este artículo pueda dar un poco de luz aquellas organizaciones que estén empezando un procesos similar o estén reflexionando sobre ello, y da continuidad al artículo ¿cómo comparar servicios en el panorama actual? ¿coste y/o calidad?

 

 

Mª Carmen Bauset-Carbonell Doctora Informática por la Universidad Politécnica de Valencia (UPV). Más de 15 años de experiencia laboral en el sector TIC. Desde 2009, Gerente de Servicios TI de INDRA. ITIL Expert (EXIN), auditor y consultor ISO 20000 (EXIN). Profesor acreditado por EXIN. Profesor Master ITIO de la UPV. Microsoft Certified Systems Engineer. Miembro comité AENOR GT25. Alboraya, España.