Situación del cliente
Una de las mayores aseguradoras del mundo —con operaciones en más de 50 países, múltiples líneas de negocio (vida, no vida, salud, reaseguro) y varios miles de aplicaciones en su portfolio TI— había completado la fase inicial de adopción cloud sobre Azure con una Landing Zone de primera generación. Tres años después, la plataforma acumulaba deuda técnica de gobierno: políticas Azure inconsistentes entre regiones, ausencia de un proceso estandarizado para evaluar y priorizar migraciones de aplicaciones, y un modelo de operación cloud que requería provisión manual de entornos —con tiempos de semanas para nuevos proyectos— frenando la velocidad de adopción de los equipos de desarrollo.
La dirección de Cloud Strategy encargó la evolución completa del modelo: actualización de la Landing Zone a la versión 2 del Azure Cloud Adoption Framework, rediseño del modelo de operación (Cloud Ops), implementación del framework Route-to-Cloud para la priorización de migraciones y despliegue de la plataforma de observabilidad multi-región.
Retos
- Migrar la Landing Zone de primera generación a la arquitectura Azure LZ v2 del Cloud Adoption Framework sin interrumpir las cargas de trabajo ya desplegadas, incluyendo la consolidación de políticas Azure inconsistentes entre regiones y la reestructuración de la jerarquía de Management Groups
- Diseñar e implementar el framework Route-to-Cloud que definiera los criterios de clasificación de aplicaciones (las 5Rs extendidas con criterios específicos del sector seguros: regulación local, sensibilidad de datos de asegurados, dependencias de mainframe) y el proceso de priorización del backlog de migración por valor de negocio
- Rediseñar el modelo de operación Cloud Ops con roles, responsabilidades y procesos ITIL integrados con la operativa cloud, transformando el equipo de infraestructura tradicional en un equipo de Cloud Engineering capaz de operar la plataforma con el nivel de automatización requerido
- Construir la plataforma de observabilidad multi-región que proporcionara visibilidad unificada del rendimiento, disponibilidad y seguridad de la plataforma cloud en todas las geografías donde opera la aseguradora, con alertas consolidadas y cuadros de mando ejecutivos
- Eliminar el proceso manual de provisión de entornos —que tardaba semanas— reemplazándolo con pipelines de IaC que entregaran entornos cloud completos y conformes a las políticas corporativas en pocas horas, sin requerir intervención del equipo de Cloud Ops para cada provisión
Solución
- Azure Landing Zone v2: migración de la jerarquía de Management Groups al modelo canónico del CAF v2 (Platform, Landing Zones, Decommissioned, Sandbox), consolidación de más de 200 políticas Azure inconsistentes en un conjunto de iniciativas de política centralizadas con herencia desde la raíz, y configuración del Connectivity Subscription con Azure Virtual WAN para la conectividad multi-región que reemplazó la arquitectura Hub-Spoke de primera generación
- Framework Route-to-Cloud: metodología de evaluación de aplicaciones con siete criterios de clasificación adaptados al sector seguros (regulación local de datos de asegurados, dependencias de sistemas mainframe, criticidad para emisión de pólizas, SLA de disponibilidad, complejidad técnica de migración, coste de licencias en cloud y valor estratégico) y proceso de gestión del backlog de migración con comité de priorización trimestral
- Cloud Ops v2: nuevo modelo operativo con tres equipos (Cloud Platform Engineering para el desarrollo de la plataforma, Cloud Operations para la operativa 24x7 y Cloud FinOps para el gobierno del coste), procesos ITIL adaptados a la velocidad cloud (Change Management con fast-track para cambios de bajo riesgo, Incident Management con runbooks cloud-native), y OKRs de equipo que medían la velocidad de adopción de los equipos internos como indicador de salud del servicio
- Plataforma de observabilidad multi-región: Azure Monitor con workspace centralizado de Log Analytics para la agregación de métricas y logs de todas las regiones, Azure Managed Grafana para los cuadros de mando operativos y ejecutivos, Workbooks personalizados para el seguimiento de los KPIs de adopción cloud por región y línea de negocio, y integración con Microsoft Sentinel para correlacionar eventos de seguridad con incidentes operativos
- IaC self-service: catálogo de patrones de arquitectura como módulos Bicep (Landing Zone completa, entorno de aplicación, plataforma de datos básica, entorno de seguridad) publicados en Azure DevOps, con pipeline de validación automática (policy compliance check antes del despliegue) y proceso de self-service que permitía a los equipos de desarrollo solicitar y recibir un entorno cloud completo en menos de 4 horas sin intervención manual del equipo de Cloud Ops
Resultados
Semanas → <4 horasreducción del tiempo de provisión de entornos cloud completos mediante el catálogo IaC self-service, eliminando el proceso manual que tardaba semanas y acelerando la velocidad de adopción de los equipos de desarrollo de la aseguradora
LZ v2 sin interrupcionesmigración de la Landing Zone de primera generación a Azure LZ v2 con consolidación de más de 200 políticas inconsistentes, sin interrupciones de las cargas de trabajo en producción durante el proceso de migración
Route-to-Cloud operativoframework de clasificación y priorización de aplicaciones para migración en operación autónoma del equipo del cliente, con backlog de migración priorizado por valor de negocio y comité de revisión trimestral como proceso estándar de governance cloud
Observabilidad unificadavisibilidad consolidada de rendimiento, disponibilidad y seguridad de todas las regiones cloud de la aseguradora desde un único workspace de Log Analytics y cuadros de mando Grafana, con KPIs de adopción por región y línea de negocio
Patrón de arquitectura
// ARCH 41 · Azure · Cloud Ops v2 · LZ v2 · Insurance Global
Cloud Ops Insurance — LZ v2 + Route-to-Cloud + IaC Self-Service + Observability
Evolución de la plataforma cloud de aseguradora global: migración a Azure LZ v2 con Management Groups canónicos CAF, consolidación de 200+ políticas inconsistentes, Virtual WAN multi-región; framework Route-to-Cloud con 7 criterios sectoriales para priorización de migraciones; Cloud Ops v2 con equipes de Platform Engineering, Operations y FinOps; IaC self-service con catálogo Bicep que reduce la provisión de entornos de semanas a menos de 4 horas; y observabilidad unificada con Azure Monitor, Grafana y Sentinel.
Azure Landing Zone v2Azure Virtual WANAzure PolicyBicep / IaCAzure MonitorAzure Managed GrafanaMicrosoft Sentinel
// Consideraciones de arquitectura · Cloud Ops Insurance WAF
- La migración de LZ v1 a v2 sin interrupciones requiere un plan de flight path, no una migración big bang — las cargas de trabajo en producción no pueden detenerse para migrar la jerarquía de Management Groups. El flight path define la secuencia exacta de migraciones de suscripciones a la nueva jerarquía, empezando por entornos de desarrollo y terminando por producción, con validación de políticas antes de cada migración.
- Los 200+ políticas inconsistentes son técnicamente migrables pero organizativamente complejas — cada política tiene un owner en algún equipo de la organización. La consolidación de políticas no es un trabajo técnico de Azure, es un trabajo político de alinear a los owners en un estándar corporativo. Sin un proceso de governance claro (quién aprueba el estándar, cómo se gestiona la excepción), la consolidación no se sostiene.
- Route-to-Cloud en seguros debe incluir la regulación local como criterio de primer nivel — en una aseguradora global, muchos países tienen requisitos de residencia de datos de asegurados o limitaciones para usar cloud público para determinados tipos de datos. Ignorar este criterio en la clasificación Route-to-Cloud genera sorpresas tardías: aplicaciones clasificadas para migrar que no pueden migrar sin violar la regulación local.
- El IaC self-service solo funciona si el catálogo de módulos se mantiene actualizado — un catálogo Bicep con módulos desactualizados que no cumplen las políticas actuales genera entornos no conformes que la política de Azure bloquea después del despliegue, con peor experiencia para el desarrollador que el proceso manual. El catálogo debe tener un proceso de mantenimiento tan riguroso como el del código de producción.
- La observabilidad multi-región centralizada tiene un coste de ingesta que debe gestionarse con FinOps — centralizar los logs de todas las regiones en un workspace de Log Analytics de Azure Monitor puede generar costes de ingesta significativos si no se definen qué logs se centralizan (todos los de seguridad, muestra de rendimiento, solo errores) vs. qué logs se quedan en workspaces regionales. El diseño de la observabilidad debe incluir el modelo de datos y el coste estimado de ingesta por región.
- El Cloud Ops v2 necesita métricas de adopción, no solo de disponibilidad — el equipo de Cloud Ops en una aseguradora global tiene éxito cuando los equipos de desarrollo migran más rápido y con menos fricción, no solo cuando la plataforma está disponible al 99,9%. Los OKRs del equipo deben medir el time-to-environment, el NPS interno de los equipos de desarrollo y el porcentaje de entornos self-service vs. provisión manual.
Excelencia OperacionalSeguridadFiabilidadOptimización de costes