Compartir vía


Revisión y comparación de modelos operativos comunes en la nube

Los modelos operativos son únicos y específicos de la empresa que admiten, en función de sus requisitos y restricciones actuales. Sin embargo, los modelos operativos no son copos de nieve. Hay varios patrones comunes en los modelos operativos del cliente; En este artículo se describen los cuatro patrones más comunes.

Comparación de modelos operativos

En la imagen siguiente se asignan modelos operativos comunes basados en el intervalo de complejidad, desde el menos complejo (descentralizado) hasta el más complejo (operaciones globales). En las tablas siguientes se comparan los mismos modelos operativos en función del valor relativo de algunos otros atributos.

Diagrama que muestra los grados de complejidad del modelo operativo.

Prioridades o ámbito

Un modelo operativo en la nube se basa principalmente en dos factores:

  • Prioridades o motivaciones estratégicas
  • Ámbito de la cartera que se va a administrar
Operaciones descentralizadas Operaciones centralizadas (op.) Operaciones empresariales Operaciones distribuidas
prioridades o motivaciones estratégicas Innovación Control Democratización Integración
Alcance del portafolio Carga de trabajo Zona de aterrizaje Plataforma en la nube Cartera completa
entorno de carga de trabajo Alta complejidad Baja complejidad Complejidad media Complejidad media o variable
Zona de aterrizaje N/A Alta complejidad Complejidad media a baja Baja complejidad
Utilidades de fundamentos N/A Soporte N/A o bajo Centralizado y con mayor respaldo Respaldo máximo
Fundamentos de nube N/A N/A Fundamentos híbridos, específicos del proveedor o regionales Distribuido y sincronizado
  • Prioridades estratégicas o motivaciones de : cada modelo operativo ofrece las motivaciones estratégicas típicas para la adopción de la nube. Pero algunos modelos operativos simplifican las motivaciones específicas.

  • Ámbito de Cartera: El ámbito de cartera identifica el mayor ámbito que admite un diseño de modelo operativo específico. Por ejemplo, las operaciones centralizadas están diseñadas para algunas zonas de aterrizaje. Pero la decisión del modelo operativo podría crear riesgos operativos para una organización. Los riesgos operativos resultan al intentar administrar una cartera compleja de gran tamaño. Estas carteras pueden requerir muchas zonas de aterrizaje o complejidad variable en el diseño de la zona de aterrizaje.

Importante

La adopción de la nube a menudo desencadena la reflexión sobre el modelo operativo actual y podría dar lugar a un cambio de un modelo operativo común a otro. Pero la adopción de la nube no es el único desencadenador. Las prioridades empresariales y el ámbito de la adopción de la nube pueden cambiar el modo en que se debe respaldar la cartera. Además, podría haber otros cambios en el modelo operativo alineado más adecuado. Cuando el consejo, u otros equipos ejecutivos, desarrollan planes empresariales de 5 a 10 años, esos planes suelen incluir un requisito (explícito o implícito) para ajustar el modelo operativo. Los modelos operativos son una buena referencia para guiar las decisiones. Estos modelos pueden cambiar o tener que personalizarse para satisfacer sus requisitos y restricciones.

Alineación de responsabilidad

Muchos equipos y personas son responsables de apoyar diferentes funciones. Pero cada modelo operativo común asigna responsabilidad final para los resultados de la decisión a un equipo o individuo. Este enfoque afecta a cómo se financia el modelo operativo y qué nivel de soporte se proporciona para cada función.

Operaciones descentralizadas Operaciones centralizadas Operaciones empresariales Operaciones distribuidas
Alineación empresarial Equipo de cargas de trabajo estrategia de nube central CCoE Variable: ¿constituyen un amplio equipo de estrategia en la nube?
operaciones en la nube Equipo de cargas de trabajo TI central CCoE Basado en el análisis de la cartera: consulte Alineación empresarial y Compromisos empresariales
gobernanza en la nube Equipo de cargas de trabajo TI central CCoE varias capas de gobernanza
seguridad en la nube Equipo de cargas de trabajo Security Operations Center (SOC) / Función DevSecOps CCoE + SOC Mixto: consulte Definición de una estrategia de seguridad
Cloud Automation y DevOps Equipo de cargas de trabajo TI central o N/A CCoE Basado en el análisis de la cartera: consulte Alineación empresarial y Compromisos empresariales

Aceleración de la implementación del modelo operativo en Azure

Como se describe en Definir el modelo operativo, cada metodología de Cloud Adoption Framework proporciona una ruta estructurada para desarrollar el modelo operativo. Estas metodologías pueden ayudarle a superar los bloqueadores que derivan de brechas en la adopción del modelo operativo en la nube.

En la tabla siguiente se describen las formas de acelerar la implementación del modelo operativo.

Operaciones descentralizadas Operaciones centralizadas Operaciones empresariales Operaciones distribuidas
punto de partida Marco de buena arquitectura de Azure (WAF) Zonas de aterrizaje de Azure: opciones de inicio a pequeña escala Zonas de aterrizaje de Azure: CAF de escala empresarial Alineación empresarial
Iteraciones Centrarse en las cargas de trabajo permite que el equipo itere dentro del WAF. La opción start-small requiere más iteración en cada metodología, pero se puede realizar a medida que maduran los esfuerzos de adopción de la nube. Como se muestra en las implementaciones de referencia, las iteraciones futuras suelen centrarse en las adiciones de configuración secundarias. Revise las opciones de implementación de la zona de aterrizaje de Azure para empezar con la opción que mejor cumpla la línea base de operaciones. Siga la ruta de iteración definida en los principios de diseño de esa opción.

Operaciones descentralizadas

Operaciones descentralizadas

Las operaciones siempre son complejas. Si limita el ámbito de las operaciones a una carga de trabajo o a una pequeña colección de cargas de trabajo, controlará la complejidad. Las operaciones descentralizadas son las menos complejas de los modelos operativos comunes. En esta forma de operaciones, todas las cargas de trabajo funcionan de forma independiente por parte de los equipos de cargas de trabajo dedicados.

  • Prioridades: Tu equipo valora la innovación en lugar del control centralizado o la normalización entre múltiples cargas de trabajo.
  • Ventaja única: maximiza la velocidad de innovación otorgando a los equipos de cargas de trabajo y de la empresa un control total del diseño, la compilación y las operaciones.
  • clara desventaja: reducción en la normalización entre distintas cargas de trabajo, economías de escala a través de servicios compartidos y esfuerzos centralizados de gobernanza coherentes en el cumplimiento.
  • riesgo: este enfoque introduce riesgos al administrar una cartera de cargas de trabajo. Es posible que los equipos de carga de trabajo tengan equipos especializados dedicados a las funciones de TI centrales. Este modelo operativo se ve como una opción de alto riesgo por parte de algunas organizaciones, especialmente las empresas necesarias para seguir los requisitos de cumplimiento de terceros.
  • Guía: las operaciones descentralizadas se limitan a decisiones en el nivel de cargas de trabajo. Microsoft Azure Well-Architected Framework apoya las decisiones tomadas dentro de ese ámbito. Los procesos e instrucciones dentro de Cloud Adoption Framework podrían agregar sobrecarga que no son necesarias para las operaciones descentralizadas.

Ventajas de las operaciones descentralizadas

  • cost management: el costo de las operaciones se asigna fácilmente a una sola unidad de negocio. Las operaciones específicas de la carga de trabajo admiten una mayor optimización de esta.
  • Responsabilidades: normalmente, esta forma de operaciones depende en gran medida de la automatización para minimizar la sobrecarga. Las responsabilidades tienden a centrarse en DevOps y pipelines para la gestión de lanzamientos. Este tipo de operaciones admite implementaciones más rápidas y ciclos de comentarios más cortos durante el desarrollo.
  • Normalización: Utilice un código fuente y una canalización de implementación para estandarizar el entorno de una versión a otra.
  • Soporte de operaciones: Las decisiones que afectan a las operaciones se basan únicamente en las necesidades de esa carga de trabajo y simplifican las decisiones operativas. Los miembros de la comunidad de DevOps dicen que el soporte de operaciones es la forma más pura de operaciones debido al ámbito operativo más estricto.
  • Experiencia: los equipos de DevOps y de desarrollo están más capacitados para este enfoque y experimentan una menor resistencia a realizar cambios en el mercado.
  • diseño de zona de aterrizaje: ninguna ventaja operativa específica.
  • utilidades fundamentales: ninguna ventaja operativa específica.
  • separación de obligaciones: ninguna ventaja operativa específica.

Desventajas de las operaciones descentralizadas

  • cost management: los costos empresariales son más difíciles de calcular. La falta de equipos de gobernanza centralizados dificulta la implementación de controles uniformes de costos o optimización. A escala, este modelo puede ser costoso, ya que cada carga de trabajo puede tener duplicación en recursos implementados y asignaciones de personal.
  • Responsabilidades: la falta de soporte técnico centralizado significa que el equipo de cargas de trabajo es totalmente responsable de la gobernanza, seguridad, operaciones y administración de cambios. La falta de soporte técnico es problemática cuando esas tareas no se han automatizado en las canalizaciones de revisión y versión de código.
  • Estandarización: La estandarización en una cartera de cargas de trabajo es variable e inconsistente.
  • Compatibilidad con operaciones: a menudo se pierden las eficiencias de escalado al crear procedimientos recomendados en varias cargas de trabajo.
  • experiencia: los miembros del equipo tienen una mayor responsabilidad para tomar decisiones sabias y éticas sobre la gobernanza, la seguridad, las operaciones y la administración de cambios dentro del diseño y la configuración de la aplicación. Consulte la Revisión de Microsoft Azure Well-Architected y Azure Well-Architected Framework con frecuencia para mejorar la competencia requerida.
  • diseño de zona de aterrizaje: las zonas de aterrizaje no son específicas de la carga de trabajo y no se consideran en este enfoque.
  • utilidades fundamentales: pocos servicios fundamentales (si los hay) se comparten entre cargas de trabajo, lo que reduce las eficiencias de escala.
  • Separación de obligaciones: unos requisitos más altos de los equipos de DevOps y de desarrollo aumentan el uso de privilegios elevados de esos equipos. Si necesita separar las tareas, es posible que tenga que invertir mucho en la madurez de DevOps para operar con este enfoque.

Operaciones centralizadas

operaciones centralizadas

Es posible que los entornos de estado estables no requieran centrarse en la arquitectura o en requisitos operativos distintos de las cargas de trabajo individuales. Las operaciones centrales tienden a ser la norma para los entornos tecnológicos que constan principalmente de cargas de trabajo de estado estable. Algunos ejemplos de operaciones de estado estable incluyen aplicaciones comerciales de uso general (COTS) o aplicaciones personalizadas bien establecidas que tienen un lento ciclo de lanzamiento. Si una tasa de cambio está controlada por actualizaciones y revisiones periódicas, la centralización de las operaciones podría ser una manera eficaz de administrar su cartera.

  • Prioridades: Las prioridades son el control central de la innovación y miden los procesos operativos existentes en relación con el cambio cultural hacia las operaciones modernas en la nube.
  • Ventaja distinta: la centralización introduce economías de escala, controles óptimos y operaciones estandarizadas, y funciona mejor con el entorno de nube. Estos entornos necesitan configuraciones específicas para integrar las operaciones en la nube en las operaciones y procesos existentes. La centralización es más ventajosa con una cartera de unos cientos de cargas de trabajo con requisitos de cumplimiento y complejidad arquitectónica modestos.
  • Inconveniente único: el uso del escalado para satisfacer las demandas de una gran cartera de cargas de trabajo puede poner mucha tensión en los equipos centralizados que toman decisiones operativas para las cargas de trabajo de producción. Si los activos técnicos esperan escalar más allá de 1000 máquinas virtuales, aplicaciones u orígenes de datos, puede considerar un modelo empresarial si es dentro de un plazo de 18 a 24 meses.
  • Riesgo: Este enfoque reduce la centralización a un número menor de suscripciones (a menudo a una suscripción de producción). Existe un riesgo significativo cuando se realiza la refactorización en etapas posteriores de su recorrido en la nube, y esto puede interferir con sus planes de adopción. Para evitar volver a trabajar, intente centrarse en la segmentación, los límites del entorno, las herramientas de identidad y otros elementos fundamentales.
  • Guía: Las opciones de implementación de las zonas de inicio de Azure que están alineadas con la velocidad de desarrollo "comenzar de forma modesta y expandirse" crean un punto de partida sólido. Puede usar estas opciones para acelerar los esfuerzos de adopción. Pero para tener éxito, establezca directivas claras para guiar los esfuerzos de adopción temprana dentro de tolerancias de riesgo aceptables. Las metodologías de gobernanza y administración ayudan a crear procesos para madurar las operaciones en paralelo. La realización de estos pasos sirve como etapas intermedias que se deben completar antes de permitir un mayor riesgo a medida que las operaciones se consolidan.

Ventajas de las operaciones centralizadas

  • administración de costos: centralizar los servicios compartidos en muchas cargas de trabajo crea economías de escala y elimina las tareas duplicadas. Los equipos centrales pueden implementar rápidamente reducciones de costos mediante optimizaciones de tamaño y escala de toda la empresa.
  • Responsabilidades: la expertización centralizada y la estandarización pueden dar lugar a una mayor estabilidad, un mejor rendimiento operativo y interrupciones mínimas relacionadas con los cambios. Este enfoque reduce las grandes presiones de aptitudes de los equipos centrados en las cargas de trabajo.
  • normalización: en general, la normalización y el costo de las operaciones es menor con un modelo centralizado porque hay menos sistemas o tareas duplicados.
  • Apoyo a las operaciones: reducir la complejidad y centralizar las operaciones facilita a los equipos de TI más pequeños el apoyo a las operaciones.
  • Experiencia: Centralizar equipos de soporte técnico permite a los expertos en seguridad, riesgo, gobernanza y operaciones impulsar decisiones críticas para la empresa.
  • diseño de zona de aterrizaje: TI central reduce la complejidad al minimizar el número de zonas de aterrizaje y suscripciones. Los diseños de zona de aterrizaje tienden a imitar los diseños anteriores del centro de datos, lo que reduce el tiempo de transición. A medida que avanza la adopción, es posible que los recursos compartidos se muevan a una suscripción o base de plataforma independiente.
  • Herramientas básicas: Llevar los diseños existentes del centro de datos a la nube da como resultado servicios fundamentales y compartidos que imitan las herramientas y operaciones locales. Cuando las operaciones locales son el modelo operativo principal, puede ser una ventaja, pero tenga en cuenta algunas desventajas. Las operaciones locales reducen el tiempo de transición, capitalizan las economías de escala y admiten procesos operativos coherentes entre cargas de trabajo hospedadas en la nube y locales. Este enfoque puede reducir la complejidad y el esfuerzo a corto plazo y permitir que los equipos más pequeños admitan operaciones en la nube con curvas de aprendizaje reducidas.
  • separación de funciones: la separación de funciones es clara en las operaciones centrales. El equipo de TI central mantiene el control de los entornos de producción y reduce la necesidad de que otros equipos requieran permisos elevados. Este enfoque reduce las infracciones limitando el número de cuentas con privilegios elevados.

Desventajas de las operaciones centralizadas

  • administración de costos: los equipos centrales no siempre entienden las arquitecturas de cargas de trabajo para generar optimizaciones impactantes en el nivel de carga de trabajo. Esta falta de comprensión limita la cantidad de ahorro de costos que proviene de operaciones de carga de trabajo bien optimizadas. No comprender completamente la arquitectura de la carga de trabajo puede afectar a las optimizaciones de costos centralizadas, lo que afecta al rendimiento, la escala y otros pilares de una carga de trabajo bien diseñada. Antes de aplicar cambios en los costos de toda la empresa a cargas de trabajo de alto perfil, el equipo de TI central debe comprender y completar la revisión de Microsoft Azure Well-Architected.
  • Responsabilidades: la centralización del soporte técnico de producción y el acceso supone una carga operativa elevada en algunas personas y una mayor presión sobre cada individuo. Las presiones colocadas en estas personas provocan la necesidad de realizar revisiones más profundas de las cargas de trabajo implementadas, que validan el cumplimiento de los requisitos detallados de cumplimiento y gobernanza de seguridad.
  • normalización: los enfoques centrales de TI dificultan la estandarización sin un escalado lineal del personal de TI central.
  • Apoyo a operaciones: las mayores desventajas de este enfoque están asociadas a una gran escala y a cambios que afectan la innovación.
  • Conocimientos: expertos en desarrollo y DevOps corren el riesgo de estar infravalorados o demasiado limitados en este tipo de entorno.
  • diseño de zona de aterrizaje: los diseños del centro de datos se basan en las restricciones de los enfoques anteriores, que no siempre son relevantes para la nube. Siguiendo este enfoque, se reducen las oportunidades de replantear la segmentación del entorno y capacitar las oportunidades de innovación. La falta de segmentación de zona de aterrizaje aumenta el efecto potencial de la vulneración, la complejidad de la gobernanza y el cumplimiento normativo, y podría crear bloqueadores para la adopción en el recorrido de la nube. Consulte la sección de riesgos anterior.
  • utilidades fundamentales: durante la transformación digital, la nube puede convertirse en el modelo operativo principal. Las herramientas centrales, creadas para las operaciones locales, reducen las oportunidades de modernizar las operaciones y aumentan las eficiencias operativas. La elección de no modernizar las operaciones al principio del proceso de adopción también es una opción. La modernización se puede lograr con la creación de una suscripción a una base de plataforma en el recorrido de adopción de la nube. Ese esfuerzo puede ser complejo, costoso y lento sin un planeamiento avanzado.
  • separación de funciones: Las operaciones centrales suelen seguir una de dos rutas, y ambas podrían dificultar la innovación.
    • opción 1: a los equipos fuera de TI central se les concede acceso limitado a los entornos de desarrollo que imitan la producción. Esta opción impide la experimentación.
    • opción 2: Teams desarrolla y realiza pruebas en entornos no compatibles. Esta opción dificulta los procesos de implementación y ralentiza las pruebas de integración posteriores a la implementación.

Operaciones empresariales

operaciones empresariales

Las operaciones empresariales son el estado de destino sugerido para todas las operaciones en la nube. Las operaciones empresariales equilibran la necesidad de control e innovación al simplificar las decisiones y las responsabilidades. El equipo de TI central es reemplazado por un centro de excelencia en la nube más facilitador o el equipo de CCoE, que brinda apoyo a los equipos de carga de trabajo. El equipo de CCoE hace responsables a los equipos de trabajo por sus decisiones, en lugar de controlar o limitar sus acciones. A los equipos de carga de trabajo se les concede más capacidad y más responsabilidad para impulsar la innovación, dentro de límites de protección bien definidos.

  • Prioridades: las prioridades son la democratización de las decisiones técnicas. La democratización de las decisiones técnicas cambia las responsabilidades que anteriormente tenían los equipos centrales de TI a los equipos de carga de trabajo. Para lograr este cambio en las prioridades, las decisiones dependen menos de los procesos de revisión realizados por humanos. Este enfoque admite la revisión automatizada, la gobernanza y la aplicación mediante herramientas nativas de la nube.
  • Ventaja distinta: la segmentación de entornos y la separación de tareas permiten equilibrar el control y la innovación. Las operaciones centralizadas mantienen cargas de trabajo que requieren un mayor cumplimiento y operaciones de estado estables, o representan mayores riesgos de seguridad. Por el contrario, este enfoque admite la reducción del control centralizado de cargas de trabajo y entornos que requieren una mayor innovación. Las carteras más grandes podrían tener dificultades con el equilibrio entre el control y la innovación. Esta flexibilidad facilita escalar miles de cargas de trabajo reduciendo los problemas operativos.
  • desventaja distinta: lo que funcionó en el entorno local podría no funcionar bien en las operaciones en la nube empresarial. Este enfoque para las operaciones requiere cambios en muchos frentes. Los cambios culturales en el control y la responsabilidad suelen ser el mayor desafío. Los cambios operativos que siguen a los cambios culturales requieren tiempo y esfuerzos dedicados para implementarse, madurar y estabilizarse. Los cambios arquitectónicos pueden ser necesarios en cargas de trabajo estables, mientras que los turnos de herramientas son necesarios para capacitar y apoyar los cambios culturales, operativos y arquitectónicos. Estos cambios pueden requerir compromisos con un proveedor de nube principal. Los esfuerzos de adopción realizados antes de estos cambios pueden requerir un trabajo significativo que va más allá de los esfuerzos típicos de refactorización.
  • riesgo: este enfoque requiere el compromiso ejecutivo con la estrategia de cambio. También requiere el compromiso de los equipos técnicos para superar las curvas de aprendizaje y ofrecer el cambio necesario. La cooperación a largo plazo entre negocios, CCoE, TI central y los equipos de carga de trabajo es necesaria para ver las ventajas a largo plazo.
  • Guía: las opciones de la zona de aterrizaje de Azure se definen como escala empresarial. Estas opciones proporcionan implementaciones de referencia para demostrar cómo se proporcionan los cambios técnicos mediante herramientas nativas de la nube en Azure. El enfoque de escala empresarial guía a los equipos a través de los cambios operativos y culturales necesarios para aprovechar al máximo esas implementaciones. Ese mismo enfoque podría adaptar la arquitectura de referencia para configurar el entorno a fin de cumplir con su estrategia de adopción y las restricciones de cumplimiento. Al implementar la escala empresarial, las metodologías de gobernanza y administración pueden ayudar a definir procesos. Estos procesos pueden ampliar las funcionalidades de cumplimiento y operaciones para satisfacer sus necesidades operativas.

Ventajas de las operaciones empresariales

  • Administración de costos: los equipos centrales actúan en las optimizaciones entre carteras y hacen responsables a los equipos de cargas de trabajo individuales de una mayor optimización de la carga de trabajo. Los equipos centrados en la carga de trabajo están capacitados para tomar decisiones y proporcionar claridad cuando esas decisiones tienen un efecto de costo negativo. Los equipos centrales y de cargas de trabajo comparten la responsabilidad de las decisiones de costos en el nivel adecuado.
  • Responsabilidades: los equipos centrales usan herramientas nativas de la nube para definir, aplicar y automatizar barreras de protección. Los esfuerzos de los equipos de cargas de trabajo se aceleran mediante la automatización y los procedimientos de CCoE. Los equipos de carga de trabajo están capacitados para impulsar la innovación y tomar decisiones dentro de esos límites de protección.
  • Normalización: los límites de protección centralizados y los servicios fundamentales crean coherencia entre todos los entornos.
  • Soporte de operaciones: Las cargas de trabajo que requieren soporte para operaciones centralizadas se segmentan en entornos con controles de estado estable. La segmentación y la separación de las obligaciones permiten a los equipos de cargas de trabajo adoptar la responsabilidad del respaldo operativo en sus propios entornos dedicados. Las herramientas nativas automatizadas en la nube garantizan una línea base de operaciones mínima para todos los entornos con compatibilidad operativa centralizada.
  • Conocimientos: la centralización de los servicios principales, como la seguridad, el riesgo, la gobernanza y las operaciones, garantiza una adecuada experiencia centralizada. Los procesos claros y los límites de protección educan y permiten a los equipos de cargas de trabajo tomar decisiones más detalladas. Estas decisiones amplían el efecto de los expertos centralizados sin necesidad de escalar el personal linealmente con la escala tecnológica.
  • diseño de zona de aterrizaje: el diseño de zona de aterrizaje replica las necesidades de la cartera, creando límites claros de seguridad, gobernanza y responsabilidad. Estos límites son necesarios para operar cargas de trabajo en la nube. Es poco probable que las prácticas de segmentación se parezcan a las restricciones creadas por los diseños anteriores del centro de datos. En las operaciones empresariales, el diseño de la zona de aterrizaje es menos complejo, lo que permite una escala más rápida y reduce las barreras a la demanda de autoservicio.
  • utilidades fundamentales: las utilidades fundamentales se hospedan en suscripciones controladas centralmente independientes, conocidas como base de plataforma. A continuación, las herramientas centrales se canalizan a cada zona de aterrizaje como servicios de utilidad. Separar las utilidades fundamentales de las zonas de aterrizaje maximiza la coherencia y la economía de escala. Estas utilidades también crean diferencias claras entre las responsabilidades administradas centralmente y las responsabilidades de nivel de carga de trabajo.
  • separación de tareas: la separación clara de las tareas entre las utilidades fundamentales y las zonas de aterrizaje es una de las mayores ventajas del enfoque de operaciones. Las herramientas y los procesos nativos de la nube admiten el acceso y el equilibrio adecuado de control entre los equipos centralizados y los equipos de carga de trabajo. Este enfoque se basa en los requisitos de las zonas de aterrizaje individuales y las cargas de trabajo hospedadas en segmentos de zona de aterrizaje.

Desventajas de las operaciones empresariales

  • Administración de costos: los equipos centrales dependen más de los equipos de cargas de trabajo para realizar cambios de producción en las zonas de aterrizaje. Este cambio crea un riesgo para posibles saturaciones presupuestarias y un ajuste de tamaño más lento del gasto real. Los procesos de control de costos, los presupuestos claros, los controles automatizados y las revisiones periódicas deben estar en vigor pronto para evitar sorpresas de costos.
  • Responsabilidades: las operaciones empresariales requieren mayores requisitos culturales y operativos. Estos requisitos garantizan la claridad en las responsabilidades y la responsabilidad entre los equipos centrales y de carga de trabajo.
  • Es posible que los procesos tradicionales de administración de cambios o los paneles de asesoramiento de cambios (cabs) no mantengan el ritmo y el equilibrio necesarios en este modelo operativo. Estos procesos se reflejan en la automatización de procesos y procedimientos que escalan de forma segura la adopción de la nube.
  • La falta de compromiso con el cambio materializa primero en la negociación y alineación de las responsabilidades. La incapacidad de alinearse con los cambios en la responsabilidad es una indicación de que los modelos operativos de TI centrales podrían ser necesarios durante los esfuerzos de adopción de la nube a corto plazo.
  • Estandarización: la falta de inversión en barreras de protección centralizadas, o automatización, crea riesgos para la estandarización, lo que es más difícil de superar a través de procesos de revisión manuales. Las dependencias operativas entre cargas de trabajo en zonas de aterrizaje y servicios compartidos crean mayores riesgos. Estos riesgos se extienden desde la estandarización durante los ciclos de actualización o versiones futuras de utilidades fundamentales. Durante las revisiones de la base de la plataforma, es necesario realizar pruebas mejoradas o incluso automatizadas para todas las zonas de aterrizaje admitidas y las cargas de trabajo que hospedan.
  • es-ES: Soporte de operaciones: La línea de base de operaciones proporcionada mediante automatización y operaciones centralizadas podría ser suficiente para cargas de trabajo de bajo impacto o baja criticidad. Pero es posible que los equipos de carga de trabajo u otras formas de operaciones dedicadas sean necesarias para cargas de trabajo complejas o de alta importancia. Si es así, podría crear un cambio en los presupuestos de operaciones, lo que requiere que las unidades de negocio proporcionen gastos operativos a esas formas de operaciones avanzadas. Si se requiere TI central para mantener la responsabilidad exclusiva del costo de las operaciones, es posible que las operaciones empresariales sean difíciles de implementar.
  • Experiencia: Puede que los miembros del equipo de TI central necesiten desarrollar experiencia en la automatización de controles centrales que previamente se entregaban a través de procesos manuales. Además, estos equipos pueden desarrollar competencia en el uso de enfoques de infraestructura como código para definir el entorno y comprender mejor las canalizaciones de bifurcación, combinación y despliegue. Como mínimo, un equipo de automatización de plataformas podría necesitar aptitudes de toma de decisiones para comprender las decisiones tomadas por el centro de excelencia en la nube o los equipos de operaciones centrales. Es posible que los equipos de carga de trabajo necesiten desarrollar más conocimientos relacionados con los controles y los procesos que rigen sus decisiones.
  • diseño de zona de aterrizaje: el diseño de zona de aterrizaje depende de las utilidades fundamentales. Los equipos de carga de trabajo deben comprender lo que hay en el diseño y lo que está prohibido incluir. Esta comprensión puede ayudar a evitar la duplicación de esfuerzos, errores o conflictos. Para crear flexibilidad, puede tener en cuenta los procesos de excepción en el diseño de su entorno de destino.
  • utilidades fundamentales: la centralización de las utilidades fundamentales tarda tiempo. Estas utilidades finalmente consideran opciones y desarrollan soluciones que se pueden escalar para cumplir varios planes de adopción. Los retrasos en los esfuerzos de adopción temprana son posibles. Los retrasos podrían compensarse en el largo plazo debido a aceleraciones y evitación de bloqueadores más adelante en el proceso.
  • Separación de tareas: garantizar una separación clara de las tareas requiere procesos maduros de administración de identidades. Puede haber más mantenimiento asociado a la alineación adecuada de usuarios, grupos y actividades de incorporación y retirada. Es posible que tenga que adoptar nuevos procesos para dar cabida al acceso Just-In-Time a través de privilegios elevados.

Operaciones distribuidas

operaciones distribuidas

Es posible que el modelo operativo existente esté demasiado engrasado para que toda la organización cambie a un nuevo modelo operativo. Para otros usuarios, las operaciones globales y varios requisitos de cumplimiento podrían impedir que las unidades de negocio específicas realicen un cambio. En este caso, podría requerir un enfoque de operaciones de distribución. Este enfoque es, en gran medida, el más complejo, ya que requiere la integración de uno o varios de los modelos operativos mencionados anteriormente.

Aunque se desaconseja en gran medida, este enfoque de operaciones podría ser necesario para algunas organizaciones. El enfoque se relaciona principalmente con las organizaciones que tienen una colección flexible de unidades de negocio dispares, una base diversa de segmentos de clientes o operaciones regionales.

  • Prioridades: integrar varios modelos operativos existentes.
  • Estado transitorio centrado en mover toda la organización a uno de los modelos operativos mencionados anteriormente.
  • Enfoque operativo a largo plazo cuando la organización es demasiado grande o demasiado compleja para alinearse con un único modelo operativo.
  • Ventaja distinta: Integrar elementos comunes del modelo operativo de cada unidad de negocio. Este enfoque crea un vehículo para agrupar unidades operativas en una jerarquía que les ayuda a madurar operaciones mediante procesos repetibles coherentes.
  • desventaja distinta: la coherencia y la estandarización en varios modelos operativos es difícil de mantener durante períodos prolongados. Este enfoque operativo requiere un conocimiento profundo de la cartera y de cómo operan varios segmentos de la cartera tecnológica.
  • riesgo: la falta de compromiso con un modelo operativo principal podría provocar confusión entre los equipos. Use este modelo operativo cuando no haya ninguna manera de alinearse con un único modelo operativo.
  • Guía: comience con una revisión exhaustiva de la cartera, que usa el enfoque descrito en los artículos sobre alineación empresarial. Intente agrupar la cartera por el modelo operativo de estado (descentralizada, centralizada o empresarial).
  • Desarrolle una jerarquía de grupos de administración que refleje las agrupaciones de modelos operativos. Esta disposición incluye otros patrones organizativos para región, unidad de negocio u otros criterios que asignan los clústeres de cargas de trabajo de las categorías menos comunes a las más comunes.
  • Evalúe la alineación de las cargas de trabajo con los modelos operativos para encontrar el clúster de modelos operativos más relevante con el que empezar. Siga las instrucciones asignadas al modelo operativo para todas las cargas de trabajo del nodo y la jerarquía de grupos de administración.
  • Use metodologías de gobernanza y administración para buscar directivas corporativas comunes, incluidas las prácticas de administración operativa necesarias en varios puntos de la jerarquía. Aplique directivas comunes de Azure para automatizar las directivas corporativas compartidas.
  • A medida que pruebe las directivas de Azure con varias implementaciones, intente moverlas más arriba en la jerarquía del grupo de administración. Las directivas se pueden aplicar a muchas cargas de trabajo, lo que podría encontrar características comunes y necesidades de operación distintas.
  • Con el tiempo, este enfoque puede ayudarle a definir un modelo que se escala en varios modelos operativos. Este enfoque también podría unificar equipos a través de un conjunto de directivas y procedimientos comunes.

Las ventajas y desventajas de este enfoque están en blanco intencionadamente. Después de completar la alineación empresarial de su cartera, consulte la sección del modelo operativo predominante anterior para mayor claridad sobre las ventajas y desventajas.

Pasos siguientes

Obtenga información sobre la terminología asociada a los modelos operativos. La terminología le ayuda a comprender cómo encaja un modelo operativo en el tema más grande de la planificación corporativa.

Obtenga información sobre cómo una zona de aterrizaje proporciona el bloque de creación básico de cualquier entorno de adopción de la nube.