Equilibrio de prioridades en la competencia

El éxito de cualquier transformación digital viene determinado por la capacidad de las partes interesadas del negocio y la tecnología para equilibrar prioridades contrapuestas.

Al igual que otras transformaciones digitales, la adopción de la nube pone de manifiesto la existencia de prioridades contrapuestas a lo largo del ciclo de vida de la adopción. Y al igual que ocurre con otras formas de transformación, la capacidad de equilibrar esas prioridades tiene un efecto significativo en la realización del valor empresarial. Equilibrar estas prioridades contrapuestas exige conversaciones abiertas y a veces difíciles entre las partes interesadas, y a veces con los contribuyentes individuales.

Este artículo describe algunas de las prioridades contrapuestas que suelen debatirse durante la aplicación de cada metodología. Puede ayudarle a prepararse para esas discusiones al desarrollar la estrategia de adopción de la nube.

Las siguientes secciones se alinean al flujo del diagrama anterior del ciclo de vida de la adopción de la nube. Sin embargo, es importante reconocer que la adopción de la nube es un proceso iterativo, no secuencial, y que estas prioridades contrapuestas pueden reaparecer en varios momentos durante su viaje de adopción de la nube.

El tema general del enfoque del Cloud Adoption Framework

Tanto las soluciones monolíticas como la planificación avanzada se basan en una serie de supuestos que pueden resultar inexactos con el tiempo. Adoptar la nube suele ser una experiencia nueva para una empresa y sus equipos técnicos. Como ocurre con la mayoría de las experiencias nuevas, es probable que las suposiciones iniciales resulten incorrectas.

Los siguientes principios ágiles de decisiones técnicas diferidas constituyen el enfoque preferido en la mayoría de instrucciones de este marco. Este enfoque sigue un patrón coherente: establecer un estado final general, pasar rápidamente a la implementación inicial, probar y validar los supuestos y refactorizar pronto para abordar los supuestos erróneos. Este tipo de mentalidad de crecimiento maximiza el aprendizaje y minimiza los riesgos para el valor empresarial, pero requiere un cierto grado de aceptación de la ambigüedad.

La ambigüedad puede ser a veces más aterradora, o más peligrosa, que las falsas suposiciones. Aunque este marco da prioridad al aprendizaje y a abordar la ambigüedad durante la aplicación, muchas situaciones requieren que el equipo dé prioridad a enfoques basados en el análisis o en suposiciones. En las siguientes secciones se ofrece al menos un "ejemplo de ámbito ampliado" para ilustrar cuándo puede ser valiosa una segunda iteración más profunda.

Equilibrio durante la fase de estrategia

El objetivo central de la metodología de la estrategia es desarrollar la alineación entre las partes interesadas. Una vez definida, la posición estratégica alineada impulsa el comportamiento a través de cada una de las metodologías para garantizar que las decisiones técnicas se alinean con los resultados empresariales deseados. Promover la alineación entre las partes interesadas crea un conjunto común de prioridades contrapuestas: profundidad de la justificación frente a tiempo para el impacto empresarial.

Prioridades contrapuestas:

• Importancia de la justificación: Las partes interesadas a menudo desean un análisis financiero profundo y una justificación comercial completa antes de sentirse cómodas con la alineación con una dirección estratégica. Por desgracia, ese nivel de análisis podría requerir un periodo de tiempo prolongado para permitir la recopilación y el análisis de los datos.
• Tiempo para el impacto empresarial: por el contrario, las partes interesadas suelen ser responsables de tener que entregar resultados empresariales dentro de los plazos de tiempo definidos. El análisis y la valoración, que llevan mucho tiempo, pueden poner en peligro esos resultados incluso antes de que empiece el trabajo técnico.

Ámbito mínimo: Para encontrar el equilibrio adecuado es necesario que las partes interesadas debatan al principio del proceso. La metodología de estrategia sugiere limitar el ámbito de la alineación durante este esfuerzo inicial. En el enfoque sugerido, las partes interesadas se centran en alinearse en torno a un conjunto de motivaciones principales, resultados medibles y una justificación comercial de alto nivel. A continuación, las partes interesadas deberían comprometerse rápidamente con algunos proyectos o pilotos iniciales para impulsar las oportunidades de aprendizaje necesarias.

Ejemplo de ámbito ampliado: Si el análisis empresarial inicial indica un alto riesgo de afectar negativamente a la empresa, las partes interesadas podrían tener que ir más despacio y evaluar con más cautela un análisis más profundo durante la justificación comercial.

Equilibrio durante la fase de planeamiento

Al igual que durante la fase de estrategia, durante la fase de planificación es necesario equilibrar la profundidad de la planificación inicial con el retraso de las decisiones técnicas.

Prioridades contrapuestas:

• Profundidad de la planificación inicial para la implementación técnica en la nube suele basarse en muchos suposiciones. Especialmente cuando hay lagunas de competencias en el equipo, el entorno adolece de lagunas de descubrimiento, o las cargas de trabajo no tienen estados finales arquitectónicos claramente definidos. Todas estas suposiciones son habituales en los planes detallados de adopción de la nube. La experimentación, los pilotos y el análisis cualitativo son necesarios para verificar o mejorar estas suposiciones.
• Los retrasos en las decisiónes técnicas se basan en la suposición de que cuanto más tarde se tome una decisión técnica, más acertada será. Seguir los principios de la planificación ágil de productos ayuda a retrasar las decisiones técnicas, permitiendo que se tomen en el momento adecuado, basándose en información suficiente. Sin embargo, este enfoque da como resultado un grado mucho más alto de ambigüedad en el plan inicial.

Ámbito mínimo: Sugerimos enfoques ágiles de desarrollo de productos para impulsar acciones rápidas dentro de planes manejables. La metodología del planeamiento recomienda las siguientes medidas para lograr este equilibrio:

1. Realice un inventario de todo el patrimonio digital utilizando herramientas de detección automatizada, pero utilice la racionalización incremental para planificar hasta los próximos 1 a 3 meses de trabajo.
2. Asegúrese de que la alineación de la organización sea adecuada para avanzar rápidamente.
3. Cree un plan de preparación de aptitudes para el equipo asignado. Utilice la estrategia y la plantilla del plan de adopción de la nube para implementar rápidamente un trabajo pendiente inicial.

Ejemplo de ámbito ampliado: En ocasiones, la entrega de un plan de adopción de la nube puede responder a un acontecimiento comercial con limite de tiempo o de gran repercusión. Cuando el éxito requiere el movimiento de un elevado número de activos durante un periodo de tiempo fijo, los pasos anteriores suelen ir seguidos de un trabajo de planificación más profundo. La clave del éxito en estas situaciones es planificar lo suficiente para ponerse en marcha y, más adelante, planificar el compromiso completo. Este enfoque reduce la probabilidad de que la planificación bloquee los resultados comerciales.

Equilibrio durante la fase de preparación

Cuando los equipos se preparan para dar sus primeros pasos en la adopción de la nube, a menudo hay prioridades que compiten entre el tiempo de adopción y las operaciones a largo plazo. El equipo puede tener dificultades para encontrar el equilibrio entre estar bien preparado para realizar la tarea y estar bien administrado. Este esfuerzo es necesario en los entornos de TI tradicionales, en los que el hecho de desarrollar una plataforma requiere recursos físicos y ciclos de adquisición. Sin embargo, cuando se define toda la plataforma de TI en código, las tácticas de desarrollo tradicionales, como la refactorización. reducen la necesidad de estar bien administrado desde el principio.

Prioridades contrapuestas:

• Operaciones a largo plazo: a menudo, las organizaciones se ven bloqueadas por el deseo de disponer de un entorno de nube que cumpla la paridad de características con los sistemas actuales de administración de operaciones, gobernanza y seguridad. En un estudio, más del 90 % de las organizaciones necesitaban apoyo para superar esa mentalidad. Este bloqueo puede crear meses de retraso, ralentizando o impidiendo el impacto empresarial.
• Tiempo para la adopción: Las herramientas basadas en la nube como Azure Policy, Azure Blueprints y los grupos de administración pueden simplificar el proceso de refactorización en toda la plataforma de TI. Además, las zonas de aterrizaje predefinidas ofrecen recomendaciones para acelerar la implementación en un entorno que ya cumple muchos requisitos de paridad de funciones. Estas herramientas proporcionan oportunidades para acelerar el tiempo de comercialización con un efecto mínimo en las operaciones a largo plazo.

Ámbito mínimo: la metodología de preparación describe una ruta directa desde la adopción rápida a las operaciones a largo plazo. Este enfoque comienza con una introducción básica a las herramientas que puede usar para refactorizar el entorno. Las herramientas tienen en cuenta sus requisitos y le guían a una selección de zonas de aterrizaje predefinidas, cada una de las cuales se entrega con infraestructura como modelos de código. Después, puede refactorizar el código durante el transcurso de la adopción de la nube para mejorar las operaciones, la seguridad y la administración.

Ejemplo de ámbito ampliado: Para los equipos cuyo plan de adopción prevea un objetivo a medio plazo (en 24 meses) de hospedar más de 1000 recursos (aplicaciones, infraestructura o activos de datos) en la nube, recomendamos una visión más sólida de las zonas de aterrizaje. En estas situaciones, debe tener en cuenta las metodologías de Gobernanza y Administración durante sus conversaciones iniciales sobre la zona de aterrizaje. Sin embargo, esta consideración más profunda suele agregar semanas o meses a un plan de adopción de la nube. Para minimizar el efecto sobre los resultados empresariales, el equipo de adopción debe probar cargas de trabajo reales en la nube y, al mismo tiempo, crear una zona de aterrizaje más consolidada y una solución de arquitectura central.

Equilibrio durante la fase de migración

Durante la migración, los equipos de adopción suelen asumir que las cargas de trabajo se volverán a hospedar en la nube con su configuración actual. Esta suposición se contrapone a un plan previsor de rediseñar cada carga de trabajo para aprovechar mejor las capacidades de la nube. Las dos vistas no son mutuamente excluyentes y pueden ser gratuitas al administrarlas mediante un proceso común.

Prioridades contrapuestas:

• Rehospedaje: Las organizaciones suelen equiparar la migración con un enfoque lift-and-shift que replica todos los recursos en la nube en su configuración actual. Este enfoque da lugar a escasas desviaciones dentro de la cartera de TI. También es la forma más rápida de retirar recursos de un centro de datos existente.
• Rediseño: La modernización de la arquitectura de cada carga de trabajo maximiza el valor de la adopción de la nube en términos de costo, rendimiento y operaciones. Sin embargo, este enfoque es más lento y a menudo requiere acceder al código fuente de cada aplicación.

Ámbito mínimo: Durante la fase inicial de planificación, use la opción de rehospedaje para planificar, teniendo claro que esta elección se basa en una hipótesis empresarial inicial y no es una decisión técnica. En la metodología de migración, el equipo de adopción de la nube cuestiona esta suposición para cada carga de trabajo migrada. Esta metodología sigue el enfoque evaluar/migrar/promover para cada carga de trabajo o grupo de cargas de trabajo para crear una fábrica de migración. Durante la fase de evaluación, el equipo de adopción evalúa la adecuación técnica y la arquitectura de cada carga de trabajo. Ese esfuerzo de evaluación rara vez da como resultado un enfoque puro de lift-and-shift, ya que muchos de los componentes de la arquitectura tienden a seleccionarse para su refactorización y modernización.

Ejemplo de ámbito ampliado: Para cargas de trabajo críticas o de alta confidencialidad, como aplicaciones de sistema central o de microservicios multinivel, puede ser necesaria una evaluación más exhaustiva de la carga de trabajo durante la fase de evaluación. En estas situaciones de rediseño, debe utilizar Azure Well-Architected Review y Azure Well-Architected Framework para refinar los requisitos de carga de trabajo durante la evaluación.

Equilibrio durante la fase de innovación

La verdadera innovación orientada al cliente a menudo crea prioridades contradictorias entre la necesidad de ofrecer un conjunto de funciones planificadas y la aplicación de un proceso de desarrollo orientado al cliente.

Prioridades contrapuestas:

• Centrado en las características: los planes iniciales de innovación se basan en el patrimonio digital existente y en las funcionalidades de la nube para ofrecer un conjunto de características que satisfagan las necesidades de un cliente. Es fácil permitir que el plan impulse la implementación técnica, lo cual conduce a un esfuerzo de desarrollo centrado en las características. A menudo, este enfoque conduce a la satisfacción temporal de las partes interesadas, pero reduce la probabilidad de impulsar innovaciones que influyan en el comportamiento de los clientes.
• Empatía con el cliente: los planes iniciales son una parte importante del aspecto empresarial del desarrollo y deben incluirse en los informes normales. Sin embargo, el aprendizaje, medición y creación con la empatía del cliente como objetivo es una medida más adecuada de éxito en un esfuerzo de innovación. Centrarse en los clientes por encima de las características tiene más probabilidades de generar satisfacción de los clientes e impacto empresarial a corto y largo plazo.

Ámbito mínimo: la metodología de innovación muestra cómo integrar la estrategia y los planes mediante el consenso sobre el valor empresarial. En la guía se presentan, a continuación, las herramientas nativas de la nube que pueden acelerar cada materia de innovación y los procedimientos recomendados para su implementación. Por último, en la sección de mejoras de procesos se muestran enfoques para la creación de empatía con el cliente al tiempo que se respetan los planes y estrategias del recorrido de adopción de la nube. Este enfoque se centra en ofrecer innovación con el uso de la menor tecnología posible.

Ejemplo de ámbito ampliado: A veces, una innovación depende de cargas de trabajo críticas o de alta confidencialidad. Cuando el cliente es un usuario interno, el esfuerzo de desarrollo puede ser tanto crítico como de alta confidencialidad durante las primeras iteraciones. En estos casos, los equipos de adopción deben utilizar Azure Well-Architected Review y Azure Well-Architected Framework para evaluar el diseño arquitectónico avanzado al principio del proceso.

Equilibrio durante la fase de gobernanza

La práctica de la gobernanza en la nube es un equilibrio entre dos prioridades contrapuestas: velocidad y agilidad frente a un entorno bien gobernado. El equipo de gobernanza en la nube se centra en evaluar y minimizar los riesgos para la empresa mediante controles uniformes y la reducción de los cambios. El equipo de adopción se centra en impulsar resultados empresariales, los cuales requieren nuevos riesgos y generan cambios de forma inherente.

Prioridades contrapuestas:

• Bien gobernado: cada control diseñado para minimizar el riesgo bloquea algún aspecto de cambio o limita las opciones de diseño. El control es esencial para un entorno bien gobernado. Sin embargo, cuando los controles se diseñan e implementan de manera aislada, pueden ser tan perjudiciales como los riesgos que pretenden evitar.
• Velocidad y agilidad: la velocidad y la agilidad son requisitos empresariales fundamentales en la economía digital. Ambos requieren la posibilidad de impulsar el cambio con elementos de bloqueo mínimos para la innovación o la adopción. Pero cuando el cambio se impulsa sin gobernanza, genera nuevos riesgos que podrían perjudicar a la empresa de formas inesperadas.

Ámbito mínimo: la metodología de gobierno recomienda que ni la gobernanza ni la adopción deben darse de manera aislada. Esta metodología comienza con una comprensión de las materias de gobernanza y una conversación sobre el riesgo empresarial, las directivas y el proceso de negocio. Como participante activo a lo largo de la adopción de la nube, el equipo de gobernanza puede aplicar un conjunto mínimo de límites de protección para afrontar los riesgos tangibles dentro del plan de adopción de la nube. Con el tiempo, el equipo de gobernanza puede refactorizar y ampliar esos límites para afrontar nuevos riesgos. Este enfoque maximiza el aprendizaje y la innovación, al tiempo que reduce al mínimo el riesgo.

Ejemplo de ámbito ampliado: Cuando el riesgo empresarial es alto, especialmente al principio de la adopción, el equipo de gobernanza de la nube puede necesitar acelerar la expansión de las implementaciones de gobernanza. Puede usar las mismas instrucciones y ejercicios para agregar este nivel superior de gobernanza, pero es posible que tenga que ir más rápido. En algunos casos, incluso podría ser necesario un estado avanzado de gobernanza mientras se desarrollan las primeras zonas de aterrizaje.

Equilibrio durante la fase de administración

El modelo de negocio de TI para la administración de operaciones no ha dejado de evolucionar en la última década. A medida que el mantenimiento del hardware se aleja de la principal propuesta de valor de TI, la perspectiva sobre la administración de operaciones cambia. A medida que EL TI aumenta el foco en la entrega de valor empresarial, los equipos de administración de operaciones están en conflicto por la necesidad de equilibrar las operaciones sin operaciones y las inversiones bajas frente a las inversiones amplias.

Prioridades contrapuestas:

• Grandes inversiones: invertir por igual en la prevención de interrupciones, la recuperación rápida y la supervisión en todo el entorno es el enfoque tradicional en la administración de operaciones. Este enfoque puede resultar caro y a veces duplica los productos de apoyo proporcionados por el proveedor de la nube.
• Pocas operaciones o ninguna: Use herramientas de operaciones nativas de la nube para minimizar las tareas repetitivas y recurrentes que antes realizaban sus empleados. Al reducir estas dependencias operativas, los empleados pueden impulsar el valor de otras maneras. Sin embargo, este enfoque aislado puede dar lugar a un soporte de las operaciones de poca calidad.

Ámbito mínimo: la metodología de administración sugiere el establecimiento de una base de referencia nativa en la nube, sin operaciones. El reconocimiento de que la base de referencia sin operaciones no satisfará todas las necesidades empresariales impulsa a la empresa a definir los compromisos y adecuar mejor las inversiones. Amplíe la línea de base para satisfacer las necesidades comunes de todas las cargas de trabajo. A continuación, cree equipos de plataforma o de cargas de trabajo específicas para mantener soluciones bien administradas en un entorno bien administrado.

Ejemplo de ámbito ampliado: En la mayoría de los entornos, el valor empresarial de un pequeño porcentaje de cargas de trabajo justifica que TI realice grandes inversiones en operaciones. Para esas cargas de trabajo, el equipo de TI podría utilizar Azure Well-Architected Review y Azure Well-Architected Framework para guiar operaciones más complejas.

Equilibrio durante la fase de organización

Las prioridades contrapuestas que se describen en este artículo reflejan el esfuerzo de TI por satisfacer las demandas empresariales para ganar velocidad y agilidad. El mismo cambio aparece en los cambios en los organigramas o estructuras de equipo virtual para proporcionar un mejor soporte para los resultados empresariales. A medida que los directivos de TI influyen en las estructuras de equipo, normalmente se abordan dos prioridades contrapuestas: control centralizado frente a control delegado.

Prioridades contrapuestas:

• Control centralizado: Este modelo operativo se centra en la centralización de todos los controles necesarios para aplicar directivas rígidas. En este modelo, el departamento de TI actúa como un elemento de bloqueo de la innovación, la velocidad y la agilidad. En cambio, TI puede garantizar un mayor grado de estabilidad, cumplimiento y seguridad.
• Control delegado: En este modelo operativo distribuido, se supone que cada equipo de DevOps o de aplicaciones empresariales proporcionará su propio conjunto de controles, basado en las soluciones necesarias para cumplir los objetivos empresariales. En este modelo, TI proporciona directrices para ayudar a los equipos a evitar riesgos, pero minimiza el número de restricciones técnicas forzadas siempre que sea posible.

Ámbito mínimo: La mayoría de las organizaciones pasan por una serie de evoluciones naturales a lo largo del tiempo. La metodología de organización describe la serie de evoluciones más habitual. Se recomienda que los equipos intenten avanzar hacia una estructura de centro de excelencia en la nube (CCoE) para ofrecer enfoques de control delegados.

Ejemplo de ámbito ampliado: Muchas situaciones hacen necesario un control centralizado. Dos ejemplos de desencadenadores del control centralizado podrían ser los requisitos de cumplimiento de terceros o los riesgos de seguridad temporales. En estas situaciones, normalmente es necesario establecer directivas de limitación y controles fijos y rígidos. Sin embargo, para permitir que continúen la innovación y la adopción, recomendamos a los equipos centrales de TI que apliquen esos controles en función de la criticidad y confidencialidad de cada carga de trabajo. Proporcionar entornos con menor control, pero con un ámbito o perfil de riesgos reducido permite una mayor flexibilidad incluso cuando se necesita control.

Pasos siguientes

Aprenda a equilibrar migración, innovación y experimentación para maximizar el valor de los esfuerzos de migración a la nube.

Equilibrio de la cartera