Sabemos que cuando las organizaciones se ven impulsadas a invertir se preguntan primero ¿cuáles son los objetivos de negocio que la organización espera alcanzar?, ¿cómo encajan estos objetivos dentro de la estrategia global de la organización?

Lo anterior funciona bien para tecnología convencional [claro, si queremos mantener la estadística de que días después de que algo entra en funcionamiento, ya está desactualizado, aparecen nuevas soluciones, nuevos parches, nuevas actualizaciones y así, como gerentes de TI, sólo nos mantenemos persiguiendo la curva de valor todo el tiempo –no muy buen porvenir ¿verdad?] pero, en cuanto a la nube, ¿sabemos si nuestra estrategia de negocio está lista para la nube?^[1] –claro, y todas las demás preguntas.

¿Nos hemos preguntado si estamos pensando en la nube para ahorrar o para crecer, por un aspecto táctico o por una solución expresa y personalizada, está la infraestructura “completamente” o “en gran medida” optimizada para la estrategia de [nuestro] negocio? ¿Hemos definido los criterios para evaluar lo anterior? ¿No? bueno, deberíamos. Tengamos presente también que cuando existe una relación con uno o más proveedores externos, la transición a la nube [o de la nube] suele complicarse.

Sería bueno encontrar maneras en que las tecnologías de nube se ajusten a las necesidades y capacidades únicas de su organización [sincerando -alineando- la infraestructura de TI con los requerimientos del negocio y asegurando que la estrategia en nube evoluciona en consonancia]. Así, conviene adoptar la tecnología en nube con la misma seriedad que se aplica a los mecanismos de despliegue de TI más tradicionales. Atención, la madurez en la nube no significa abandonar las nubes privadas, sino el uso de la herramienta adecuada para la tarea y, en última instancia, el alineamiento de la estrategia en infraestructura y la gobernanza.

No olvidemos a los “nativos digitales” y su continua ansia por la nueva y menor tecnología que puedan comprar -¿alguien ha explotado todo lo que esta nueva tecnología puede hacer? ¿Recuerdan cuando La gente estaba acostumbrada a tener una mejor tecnología en el trabajo de la que tenía en casa [y estaban menos propensos a cuestionar el hecho]? Claro, BYOD –flexibilidad, agilidad, adaptabilidad, rendimiento, escalabilidad, rapidez[2], libertad… fomentando una cultura que hace uso seguro de la tecnología digital[3] [pero asegúrese de que la seguridad, la privacidad y el cumplimiento legal se abordan desde el principio –no olvide desarrollar las estructuras de gobierno exigidas por la nube, y adaptar o remodelar los procesos de gobierno para implicar más a los líderes]. La leyenda urbana dice que para ampliar el uso de la nube con responsabilidad y cosechar sus beneficios, las empresas deben ser capaces de utilizar la nube de forma segura.

Preparémonos para invertir más tiempo y esfuerzo en evaluar un número creciente de proveedores de nube (IaaS, PaaS, SaaS, XaaS para el caso) y soluciones puntuales –ojo con las soluciones “llave en mano” ya sean propietarias (Amazon y Microsoft entre otras) o de código abierto[4] (OpenStack). El entorno se complica cuando se involucra a otros grupos de interés internos como responsables de la conformidad (la aceptación de la implantación y la migración podría ser complicada por lo que debemos asegurar el cumplimiento legal y normativo), y líderes de negocio –seguramente habrán dudas en cuanto a la seguridad de la información. En última instancia, todos debemos prepararnos para la transición. Acuerde los detalles con sus proveedores actuales –no se olvide de exigir garantías, y aproveche toda su experiencia –hasta puede obtener orientación estratégica, busquemos socios que estén preparados para mantener una relación de colaboración y aprendizaje constantes (sería ideal compartir ideas sobre mejoras en la tecnología y la plataforma –y hasta tener la posibilidad de influir de forma innovadora en la del proveedor).

Apuesto que creían que olvido al integrador. No es así. Debemos elegir un integrador, alguien que se haga cargo de la integración de los servicio de nube, ya sea un empleado o un consultor técnico de confianza[5]. Debemos asegurar que se orqueste adecuadamente nuestra red de [los mejores] proveedores –¿o considera sabio poner todos los huevos en la misma canasta?, sin olvidar el intercambio de datos y las diferencias entre los procesos de los distintos centros de datos. Como somos entendidos en la materia nos habremos dado cuenta que para garantizar el éxito de la adopción de la nube debemos establecer un plan de ruta para esta integración‑migración y que debemos gestionar este plan [apropiadamente] como un proyecto.

Además, en la vida diaria cosas malas suceden, y nos ocurrirán cuando y donde más nos afecte -¿recuerdan a Murphy? Las necesidades del negocio cambian y más vendedores aparecen (con ofertas más atractivas) o los actuales vendedores salen del mercado (local, lo que nos deja sin soporte apropiado, o simplemente quiebran y quedamos desamparados), a veces las relaciones de nube no duran (porque no obtuvimos del proveedor los servicios –funcionalidad y soporte- como nos ofreció, porque ¿la nube no estuvo a la altura de nuestras necesidades? –y no obtuvimos las ganancias financieras esperadas[6] [en parte quizá porque en primer lugar no estuvimos “preparados” para la nube], porque hubo pérdida de datos –improbable dicen algunos pero sin embargo posible, porque el proveedor está atrasado tecnológicamente, porque se impactó negativamente en alguno de los factores CID de la seguridad de la información, porque ocurrieron apagones de la nube y permanecen en la oscuridad la gravedad y el estado exacto de los trabajos de restauración[7] -y este oscurantismo medioeval no nos gusta, entre otros aspectos a considerar).

En fin, a veces tenemos que hacer un cambio, y a veces hay eventos fuera de nuestro control que lo hacen por nosotros; así, no podemos o logramos permanecer en un servicio que es “el más adecuado”. Bien pensado, tampoco queremos vernos “atados” a un proveedor. Cuando eso sucede, tener un plan [¿sería mejor considerar una estrategia de salida?] puede significar la diferencia entre un ligero contratiempo del cual la organización puede recuperarse rápidamente, o enfrentar caos, tiempo de inactividad y una interrupción importante para el negocio.

En otras palabras, la estrategia de salida de nube [“migración en reversa” o “uncloud”[8] o “de-cloud” si nos ponemos al día con la terminología –ajá, ¿cuántos hemos reconocido estos términos?] es la elaboración de un plan de acción para asegurar que cualesquiera sean los servicios de nube que apoyan las actividades actuales del negocio, estos [servicios de nube] se pueden reemplazar [se puede realizar la transición] sin una interrupción grave[9]. El objetivo es realizar la transición en el plazo más breve posible[10] así que, entre otras cosas, no olvidemos considerar herramientas, personal calificado, niveles de servicio acordados con terceros [¿nuestros clientes?], otras responsabilidades adquiridas, mapeo de dependencias, mapeo de aplicaciones con la plataforma tecnológica, las propias aplicaciones, pruebas.

Así, tengamos presente qué servicios en nube reemplazamos e igualmente importante, con qué servicios en nube los reemplazamos –las alternativas tecnológicas pueden ser hasta iguales, pero centrémonos en lo que el negocio requiere (seguramente hemos realizado o deberemos realizar un BIA para un BCP[11] por ejemplo); así también es importante el cómo estamos utilizando los [actuales] servicios en nube (costos, rendimiento, jugadores clave, características del servicio, tratamiento de datos, niveles de servicio, soporte, aspectos legales y de cumplimiento, gobierno, no olvidemos las necesidades de privacidad y trazabilidad[12], entre otros aspectos a considerar –¿ya mencioné los factores CID de la seguridad de la información?).

Un análisis de impacto en el negocio (BIA) es un proceso sistemático mediante el cual una organización reúne y analiza información sobre sus funciones esenciales [y sus prioridades] y procesos (aplicaciones, datos, redes, sistemas de información, instalaciones, etc.). Esta información se utiliza para determinar cómo se vería afectada la organización (impacto potencial y costos en casos de desastre/acontecimiento/suceso) si estas funciones y procesos fueron interrumpidos por un desastre[13]/acontecimiento/suceso. En otras palabras, es fundamental analizar cuál es la tolerancia de su negocio a la no disponibilidad de sus funciones críticas[14]. ITIL®[15] nos dice que el BIA define los requisitos de recuperación de los servicios de TI. Estos requisitos incluyen tiempos de recuperación objetivos, puntos de recuperación objetivos y los objetivos mínimos de nivel de servicio para cada servicio de TI.

En la actualidad garantizar la operación no es una opción. Los clientes, proveedores y accionistas esperan respuesta sin importar lo que suceda en el exterior [sin importar las circunstancias que se presenten en el ecosistema donde se desarrolla la organización, sea ésta del tamaño que sea, pública, privada o entidad gubernamental]. La continuidad del negocio (BC) describe los procesos y procedimientos que una organización pone en marcha para garantizar que las funciones esenciales puedan continuar durante y después de un desastre/acontecimiento/suceso –esto no sólo involucra a TI y su Plan de recuperación ante desastres o DRP (¿alguno lo tiene? Como procedimiento documentado[16] quiero decir). La Planificación de la Continuidad del Negocio (BCP) trata de evitar la interrupción de los servicios de misión crítica (seguramente más de una vez caeremos) y restablecer el pleno funcionamiento de la forma más rápida y fácil que sea posible[17] (lo importante es levantarnos, cada vez). Usualmente los procesos críticos de negocio mantienen una íntima interdependencia con la tecnología; así, no consideremos que esto es un gasto sino más bien una inversión.

No esperamos –o deseamos- que nuestra relación con el o los proveedores de nube se vea interrumpida o falle. Pero prestemos atención al refrán: “cuando el río suena es porque piedras trae”. Otro refrán dice más o menos así: “esperamos lo mejor preparándonos para lo peor” –o que Dios nos coja confesados.

[1] Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/05/CIOs-Mapping-the-cloud-maturity-curve-The-fundamental-five.pdf, mayo/2015

[2] Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/02/CIOs-Cloud-Bound.pdf, febrero/2015

[3] Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/05/CIOs-Mapping-the-Cloud-Maturity-Curve.pdf, mayo/2015

[4] Fuente: http://www.channelbiz.es/2014/09/25/openstack-un-repaso-esta-alternativa-cloud-en-codigo-abierto/, setiembre/2014

[5] Término acuñado, a mi mejor entender, por Garcerán Rojas de PQC.es

[6] Fuente: http://searchcloudprovider.techtarget.com/tip/How-to-uncloud-Best-practices-for-exiting-the-public-cloud, noviembre/2015

[7] Fuente: http://cioperu.pe/articulo/17264/como-utilizar-openstack/, noviembre/2014

[8] Fuente: http://searchcloudprovider.techtarget.com/definition/uncloud-de-cloud, setiembre/2015

[9] Fuente: http://searchcloudsecurity.techtarget.com/tip/Create-a-cloud-exit-strategy-to-prepare-for-the-unknown?utm_medium=EM&asrc=EM_NLN_49188871&utm_campaign=20151028_Dridex%20banking%20Trojan,%20botnets%20wreaking%20havoc%20again%20despite%20DOJ%20takedown_oeckerson&utm_source=NLN&track=NL-1820&ad=903816&src=903816, octubre/2015

[10] Fuente: http://blogs.gartner.com/kyle-hilgendorf/2013/09/18/cloud-exit-strategies-you-do-need-them/, setiembre/2013

[11] Fuente: http://searchdisasterrecovery.techtarget.com/essentialguide/Essential-guide-to-business-continuity-and-disaster-recovery-plans, 2015

[12] Fuente: http://www.bbb.org/blog/2013/08/6-steps-for-de-clouding-yourself/, agosto/2013