Creación de un plan de implantación por fases

Para identificar grupos de aplicaciones que puede agrupar en la misma fase de adopción, dibuje un gráfico de cuatro cuadrantes que represente la preparación para la nube con respecto al valor de negocio para cada una de sus aplicaciones.

A continuación se muestra un ejemplo de gráfico:

La preparación para la nube captura su nivel de preparación para mover una aplicación a la nube. Por ejemplo:

• Costo

• Riesgo

• Cambio

• Restricciones técnicas

Las aplicaciones con un nivel más alto de preparación para la nube son las aplicaciones que se pueden realojar o adaptar a la nueva plataforma con mayor facilidad, o las aplicaciones que no dependen de otras aplicaciones con un bajo nivel de preparación. Las aplicaciones con un bajo nivel de preparación para la nube pueden requerir una refactorización mayor o tener dependencias significativas de otras aplicaciones que se deben reescribir para poder migrarlas.

El valor de negocio captura los objetivos. Por ejemplo:

• Automatización

• Agilidad

• Innovación

• Continuidad del negocio

El valor de negocio le ayuda a clasificar el rol que desempeña una aplicación en su negocio o la prioridad estratégica asociada al traslado de una aplicación a la nube. El valor de negocio de una aplicación es independiente de su arquitectura.

Coloque cada aplicación en un cuadrante del gráfico. Para determinar la posición adecuada, utilice el análisis de atributos que ha realizado previamente para las arquitecturas existentes y las posibles arquitecturas futuras. Las aplicaciones que planea migrar en la misma fase deben estar relativamente bien agrupadas. Si prioriza la preparación para la nube, las aplicaciones de una fase pueden abarcar el espectro de valores. Del mismo modo, si se centra en el valor de negocio en primer lugar, las aplicaciones pueden abarcar el espectro de preparación. Sin embargo, si una fase abarca más de dos cuadrantes, recomendamos que vuelva a evaluar el riesgo y el ámbito de los cambios, especialmente en el contexto de la adopción de la nube. Una excepción sería si evalúa varios proyectos paralelos y relativamente independientes, en cuyo caso debe consultar el gráfico de cada proyecto por separado.

Si tiene muchas aplicaciones heredadas esenciales y desea migrar a la nube sin el arduo requisito de reescribir esas aplicaciones, un buen punto de partida son las aplicaciones de la esquina superior izquierda, con un nivel de preparación más bajo debido a las restricciones heredadas, pero un valor de negocio más alto. Si su organización tiene aversión al riesgo, un punto de partida alternativo podrían ser las aplicaciones del cuadrante inferior derecho (nivel de preparación más alto, valor más bajo) porque están listas para migrar a la nube y un posible fallo tendría un impacto menor en la organización. Si su organización desea centrarse en un proyecto piloto inicial o necesita una oportunidad para conocer la plataforma, cualquiera de los cuadrantes con un nivel alto preparación es un buen punto de partida.

En el caso de una empresa grande, puede que tenga aplicaciones relativamente independientes y que decida adoptar diferentes enfoques paralelos a la adopción de la nube en diferentes líneas de negocio.

La creación de un plan de implantación en la nube es un proceso iterativo. Agrupe las aplicaciones en fases, asigne las aplicaciones a sus prioridades de negocio, planifique las fases para su adopción y, a continuación, realice iteraciones con las partes interesadas del negocio, estableciendo compromisos según sea necesario en cuanto a fechas, ámbito o secuencia.

Para empezar, identifique los grupos de aplicaciones que se deben abordar juntas. A continuación, observe las implicaciones de las diferentes decisiones de secuenciación. Las prioridades y las restricciones de negocio de su organización deben conformar este análisis. Los siguientes atributos suelen desempeñan el papel más importante en la agrupación de aplicaciones y la planificación de las fases de adopción:

• Gravedad de datos: ¿existen grupos de aplicaciones que no se pueden dividir entre la nube y las instalaciones locales y que se deben resolver juntas? Incluya escenarios en los que se retiren algunas aplicaciones y otras se vuelvan a realojar.

• Ámbito del cambio: para facilitar la gestión del cambio, es posible que necesite desglosar grupos grandes de aplicaciones en grupos más pequeños. La gestión del cambio se centra tanto en las personas y las habilidades como en el número de componentes tecnológicos. El realojamiento de un grupo grande de aplicaciones puede tener un ámbito de cambio menor que la refactorización y la adaptación a la nueva plataforma de un grupo más pequeño de aplicaciones.

• Tolerancia al riesgo: ¿cómo amplifica o amortigua las incertidumbres y los riesgos del proyecto el rol que desempeñan las aplicaciones en sus procesos esenciales?

• Eventos apremiantes: ¿existen factores tecnológicos de fin de vida, como el soporte de software o las actualizaciones de hardware, o cierres de inmuebles y edificios, que motiven una decisión concreta?

Al analizar la arquitectura actual y la arquitectura planificada, ha evaluado numerosos atributos. Cuando planifique las fases para la adopción, utilice también una vista agregada o de alto nivel. Los atributos enumerados anteriormente (gravedad de los datos, ámbito del cambio, tolerancia al riesgo y eventos apremiantes) son un buen sitio para empezar con una vista de alto nivel. En función de las necesidades de su negocio, puede identificar otros atributos que sean más importantes para agrupar aplicaciones en fases y validar su plan.

En su plan, muestre cómo se alinea cada fase con sus objetivos empresariales, como la creación de sistemas más resilientes, la activación de un nuevo desarrollo o el cumplimiento de algún evento apremiante. Cuando no puede realizar una fase de adopción en el orden preferido de su organización, documente los motivos por los que se ha dado prioridad a una fase concreta sobre otra.

Para validar su estrategia, haga referencia cruzada al gráfico de preparación para la nube, la matriz de funciones estratégicas, la vista agregada de atributos y otras perspectivas arquitectónicas según los atributos que haya recopilado.

La gestión del ámbito es esencial para avanzar. Realice iteraciones en pequeñas partes o incluso en subjuegos de aplicaciones. Cuando corresponda, desglose los flujos paralelos en las líneas de negocio. Si su organización puede aceptar la ambigüedad, no se comprometa con todos los detalles de las fases futuras. En su lugar, identifique puntos de decisión futuros clave y destáquelos como riesgos desconocidos o intente identificar cuándo podría tomar esas decisiones. Por ejemplo, ¿elegirá su organización una estrategia multinube o puede mantener un modelo híbrido limitado debido a requisitos de residencia de datos o a requisitos locales?

Lo que es más importante, establezca la expectativa base de que la planificación de adopción de la nube no es una actividad puntual, sino una actividad que debe iterar a medida que aprende. El cambio de planes para las fases futuras no debe considerarse un giro reaccionario en respuesta a un problema, sino como un servicio para respaldar sus objetivos empresariales en el contexto de una tecnología en la nube y un ecosistema de arquitectura en rápida evolución.