Modelo de Gobierno HERA

Resumen Ejecutivo

Este documento establece el marco normativo y operativo para el ciclo de vida del software en Grupo Herdez, asegurando consistencia, seguridad y cumplimiento.

• Gobernanza Basada en Principios: Implementa 10 principios rectores y una matriz RACI de 75+ actividades para eliminar la ambigüedad en las responsabilidades de los equipos.
• Calidad y Homologación: Define 3 niveles de cumplimiento (Bronze, Silver, Gold) que actúan como prerrequisitos mandatorios para el despliegue en ambientes productivos.
• Mitigación de Riesgos: Centraliza las decisiones arquitectónicas a través del Comité de Arquitectura (COMA) y garantiza el cumplimiento de marcos regulatorios como ISO 27001 y PCI-DSS.

Fuente única de verdad sobre el gobierno de la plataforma HERA. Define quién decide qué, las reglas de incorporación de servicios, los criterios HERA-compliant y la asignación formal de responsabilidades. Dirigido a liderazgo técnico, arquitectos, auditores externos (ISO 27001, SOC 2), gerentes de área y compliance officers.

Documento de gobernanza formal

A diferencia de las páginas operativas (cómo configurar un pipeline, cómo crear un repo), este documento define el marco de gobierno bajo el cual operan todas esas actividades. Cualquier cambio a este documento requiere aprobación del Comité de Arquitectura y queda registrado en el Decision Log con su rationale.

---

1. Propósito

El Modelo de Gobierno HERA existe para:

1. Establecer un marco único de decisión sobre cómo se construye, despliega, opera y evoluciona el software en Grupo Herdez
2. Definir formalmente las responsabilidades de cada rol en el ciclo de vida de un servicio
3. Garantizar la consistencia entre productos, equipos y partners de desarrollo
4. Cumplir requisitos regulatorios (ISO 27001, PCI-DSS, SOC 2, LFPDPPP) con evidencia documentada
5. Proteger la inversión tecnológica de Grupo Herdez evitando fragmentación, deuda técnica y duplicación
6. Habilitar autonomía con guardrails — los equipos toman decisiones libremente dentro del marco HERA, sin requerir aprobación ad-hoc

Sin gobierno explícito, el ecosistema se fragmenta. Cada equipo inventa convenciones, cada producto reimplementa lo mismo, cada decisión se relitiga. El gobierno NO es burocracia — es la base que permite escalar.

---

2. Alcance

Lo que SÍ está en alcance del Modelo de Gobierno HERA

Aspecto	Cubierto
Aplicaciones cloud-native desplegadas en GCP (GKE, Cloud Run, Cloud Functions)	✅
Pipelines CI/CD ejecutados en GitLab corporativo	✅
Infraestructura como código (Terraform, Helm) gestionada por HERA	✅
Servicios desarrollados internamente por equipos de Grupo Herdez	✅
Servicios desarrollados por Partners de Desarrollo externos	✅
Repositorios dentro del grupo grupo-herdez/ en GitLab	✅
Imágenes y artefactos publicados en Artifact Registry corporativo	✅
Datos y bases de datos creadas a través de los módulos Terraform de HERA	✅

Lo que NO está en alcance (out of scope)

Aspecto	Razón
Sistemas legacy on-premises (SAP, sistemas de manufactura, ERP)	Tienen su propio gobierno operacional. HERA gobierna integraciones con ellos pero no sus runtimes
Software comprado off-the-shelf no modificado (Salesforce, Office 365)	Gobierno corporativo de TI tradicional aplica
Workloads de proveedores externos en sus propias nubes	Fuera del ecosistema HERA
Hardware de oficinas, redes corporativas, dispositivos de usuario	Gobierno de IT general aplica

Servicios híbridos

Si un servicio es híbrido (parte cloud-HERA, parte on-premises), la parte cloud está bajo gobierno HERA. La parte on-premises sigue su propio gobierno. La integración entre ambas (vía servicios integration) está bajo HERA.

---

3. Principios Rectores de HERA

Estos son los 10 principios rectores que guían toda decisión de gobierno en HERA. Si una decisión técnica entra en conflicto con un principio, el principio gana salvo aprobación explícita del Comité de Arquitectura.

Principio 1 — Estandarizar el 80%, customizar el 20%

El equipo de plataforma construye autopistas pavimentadas (templates, golden paths, módulos) que cubren el 80% de los casos de uso. Los productos consumen estas autopistas. Solo el 20% específico del producto requiere customización.

Implicación: Si un equipo construye su propio pipeline custom, debe justificar por qué los templates de HERA no le sirven.

Principio 2 — Self-Service First

Los equipos de desarrollo deben poder operar de forma autónoma siempre que sea posible. Los tickets son la última opción, no la primera.

Implicación: El equipo de plataforma prioriza construir capacidades self-service sobre atender tickets manuales.

Principio 3 — Shift-Left en seguridad, costos y calidad

Todo lo que pueda detectarse temprano debe detectarse temprano. Seguridad, costos y calidad NO son etapas finales — son validaciones continuas en todo el ciclo.

Implicación: Los umbrales de calidad (Quality Gates) de SAST, SCA, detección de secretos y estimación de costos se ejecutan en cada MR, no al final del sprint.

Principio 4 — Build Once, Deploy Many

Una imagen Docker se construye una sola vez y se promueve de forma idéntica (bit-identical) entre ambientes (DEV → QA → PRD). Lo que valida QA es exactamente lo que va a producción.

Implicación: No se permite reconstruir imágenes por ambiente. La configuración cambia, el artefacto no.

Principio 5 — Zero Trust por defecto

Ningún componente confía en otro por defecto. Cada acceso requiere autenticación, autorización y cifrado. No hay “red interna confiable”.

Implicación: mTLS entre servicios, MFA obligatorio, principio de privilegio mínimo, denegación por defecto (default-deny) en políticas de red.

Principio 6 — Infrastructure as Code, sin excepciones

Si existe en GCP, existe en un archivo Terraform. La consola de GCP es para leer, no para escribir en producción.

Implicación: Cambios manuales en consola están prohibidos para PRD. Todo cambio de infraestructura pasa por Merge Request.

Principio 7 — Observabilidad nativa

Todo servicio nace instrumentado. Logs estructurados, métricas RED, traces distribuidos, validaciones de salud (healthchecks) y SLO definido son obligatorios desde el día 1.

Implicación: Un servicio sin observabilidad no se considera HERA-compliant.

Principio 8 — FinOps shift-left

El costo de cada decisión es visible en el momento de la decisión, no al final del mes cuando ya es tarde.

Implicación: Estimación de costos con Infracost en cada MR de infraestructura. Etiquetado (tagging) obligatorio de costos por equipo.

Principio 9 — Documentación como código

La documentación vive junto al código, se versiona, se revisa en code review y se publica automáticamente. Documentos fuera del repo no existen.

Implicación: Este portal HERA es parte del ecosistema. Cada cambio importante a un servicio actualiza su documentación.

Principio 10 — Clasificación obligatoria, sin servicios “fantasma”

Todo servicio tiene una categoría oficial (de las 13 de HERA), un dueño claro, un manifiesto (manifest) y SLOs definidos. Sin clasificación, no se crea el repo.

Implicación: El catálogo de servicios (service catalog) es la única fuente de verdad. Servicios sin manifiesto no son HERA-compliant.

---

4. Roles del Modelo de Gobierno HERA

Los roles ya están definidos en detalle en Roles y Responsabilidades. Aquí se listan resumidamente para referencia desde la matriz RACI:

Rol	Sigla	Equipo / Pertenencia
Developer	DEV	Equipo de producto
Tech Lead	TL	Equipo de producto
QA Engineer	QA	Equipo de producto / Calidad
Product Owner	PO	Negocio / Producto
Arquitecto de Soluciones	ARQ	Equipo de Arquitectura
Platform Engineer / DevOps	PE	Equipo de Plataforma HERA
SRE (Site Reliability Engineer)	SRE	Equipo de Plataforma HERA
Security Engineer	SEC	Equipo de Seguridad
DBA / Data Engineer	DBA	Equipo de Datos
Partner de Desarrollo	PART	Equipo externo (con responsabilidades equivalentes a DEV + TL)
Comité de Arquitectura	COMA	Mesa de gobierno (ARQ + PE + SEC + líderes técnicos)

---

5. Modelo RACI

La matriz RACI define formalmente quién hace qué en HERA. Es referencia obligatoria para auditores externos y para resolver disputas de responsabilidad entre equipos.

5.1 Diseño y Arquitectura

Responsable Aprobador Consultado Informado

Actividad	DEV	TL	QA	PO	ARQ	PE	SRE	SEC	DBA	COMA
Definir arquitectura de un nuevo producto	C	R	I	C	A	C	C	C	C	I
Aprobar cambio arquitectónico mayor	I	R	I	I	C	C	C	C	C	A
Diseñar contrato de API (OpenAPI)	R	A	C	C	C	I	I	C	I	I
Crear ADR (Architecture Decision Record)	C	R	I	I	A	C	I	I	I	C
Decidir patrón arquitectónico (microservicios vs modular)	C	R	I	I	A	C	I	I	I	C
Validar diseño contra principios HERA	I	C	I	I	R	C	C	C	I	A

5.2 Desarrollo de Software

Responsable Aprobador Consultado Informado

Actividad	DEV	TL	QA	PO	ARQ	PE	SRE	SEC	DBA	COMA
Escribir código de aplicación	A/R	C	I	I	I	I	I	I	I	I
Code review de Merge Request	R	A	I	I	I	I	I	I	I	I
Aprobar merge a develop	C	A/R	C	I	I	I	I	I	I	I
Aprobar merge a main (PRD)	C	A/R	R	R	I	I	I	I	I	I
Definir cobertura mínima de tests	C	A	R	I	I	I	I	I	I	I
Cumplir Conventional Commits	A/R	C	I	I	I	I	I	I	I	I
Mantener Dockerfile y dependencias	A/R	C	I	I	I	C	I	C	I	I

5.3 Pipelines CI/CD

Responsable Aprobador Consultado Informado

Actividad	DEV	TL	QA	PO	ARQ	PE	SRE	SEC	DBA	COMA
Mantener templates de pipeline por lenguaje	I	I	I	I	C	A/R	I	C	I	I
Configurar pipeline de un proyecto específico	R	A	I	I	I	C	I	I	I	I
Definir umbrales (Quality Gates) de calidad de código	C	C	C	I	C	R	I	A	I	I
Aprobar excepciones de Quality Gates	I	C	I	I	C	C	I	A/R	I	I
Investigar pipeline roto	R	A	I	I	I	C	I	I	I	I
Actualizar versiones de herramientas (SonarQube, etc.)	I	I	I	I	C	A/R	I	C	I	I

5.4 Infraestructura

Responsable Aprobador Consultado Informado

Actividad	DEV	TL	QA	PO	ARQ	PE	SRE	SEC	DBA	COMA
Mantener módulos Terraform reutilizables	I	I	I	I	C	A/R	C	C	C	I
Aprovisionar infraestructura nueva (vía ticket)	C	C	I	I	C	A/R	I	C	C	I
Aprobar cambios de infraestructura críticos	I	I	I	I	C	C	C	C	C	A
Mantener clusters GKE	I	I	I	I	I	A/R	C	C	I	I
Definir políticas de red (Network Policies)	I	I	I	I	C	R	I	A	I	I
Aprovisionar bases de datos (Cloud SQL)	C	C	I	I	I	C	I	I	A/R	I
Configurar Workload Identity para servicios	C	I	I	I	I	A/R	I	C	I	I

5.5 Despliegues y Releases

Responsable Aprobador Consultado Informado

Actividad	DEV	TL	QA	PO	ARQ	PE	SRE	SEC	DBA	COMA
Deploy automático a DEV	A/R	I	I	I	I	I	I	I	I	I
Deploy automático a QA	C	I	A/R	I	I	I	I	I	I	I
Aprobar deploy a PRD	I	C	C	A	I	I	I	C	I	I
Ejecutar deploy a PRD	A/R	C	I	I	I	I	I	I	I	I
Decidir estrategia de deploy (canary, blue/green)	C	R	C	I	C	C	A	I	I	I
Ejecutar reversión (rollback) en producción	A/R	C	C	I	I	I	C	I	I	I
Definir ventanas de deploy a PRD	I	I	I	C	I	I	A	C	I	I

5.6 Operaciones y SRE

Responsable Aprobador Consultado Informado

Actividad	DEV	TL	QA	PO	ARQ	PE	SRE	SEC	DBA	COMA
Monitorear servicios en PRD	C	C	I	I	I	I	A/R	I	I	I
Definir SLOs del servicio	C	A	C	C	I	I	R	I	I	I
Configurar alertas	C	C	I	I	I	I	A/R	I	I	I
Responder a incidentes (oncall L2)	C	C	I	I	I	I	A/R	C	I	I
Liderar análisis post-mortem de incidente	C	A	I	I	I	I	R	C	I	I
Mantener manuales operativos (runbooks)	C	C	I	I	I	I	A/R	I	I	I
Pruebas de recuperación ante desastres (DR testing)	I	I	I	I	C	C	A/R	C	C	I

5.7 Seguridad

Responsable Aprobador Consultado Informado

Actividad	DEV	TL	QA	PO	ARQ	PE	SRE	SEC	DBA	COMA
Definir políticas de seguridad	I	I	I	I	C	C	I	A/R	I	C
Configurar herramientas de scanning (SAST, SCA)	I	I	I	I	I	C	I	A/R	I	I
Triaje de vulnerabilidades Críticas y Altas	I	C	I	I	I	I	I	A/R	I	I
Remediar vulnerabilidades de código	A/R	C	I	I	I	I	I	C	I	I
Gestionar Secret Manager (rotación, accesos)	C	C	I	I	I	C	I	A/R	I	I
Aprobar excepciones de seguridad	I	C	I	I	C	I	I	A/R	I	I
Revisiones de acceso periódicas (cuatrimestral)	I	R	I	I	I	C	I	A	I	I
Investigar incidente de seguridad	C	C	I	I	I	C	C	A/R	I	I

5.8 Compliance y Auditoría

Responsable Aprobador Consultado Informado

Actividad	DEV	TL	QA	PO	ARQ	PE	SRE	SEC	DBA	COMA
Mantener certificaciones (ISO 27001, SOC 2, PCI-DSS)	I	C	I	I	I	C	C	A/R	C	I
Atender auditores externos	I	I	I	I	C	C	C	A/R	I	C
Generar reportes de compliance	I	I	I	I	I	C	I	A/R	C	I
Mantener Cloud Audit Logs configurados	I	I	I	I	I	R	I	A	I	I
Definir políticas de retención de logs	I	I	I	I	C	C	I	A/R	C	I
Validar etiquetado (tagging) obligatorio de recursos	I	C	I	I	I	A/R	I	C	I	I

5.9 Gestión de Costos (FinOps)

Responsable Aprobador Consultado Informado

Actividad	DEV	TL	QA	PO	ARQ	PE	SRE	SEC	DBA	COMA
Definir presupuesto cloud por producto	I	C	I	A	I	C	I	I	I	I
Monitorear gasto de la aplicación	C	A	I	C	I	I	I	I	I	I
Optimizar costos del servicio	A/R	C	I	I	I	C	I	I	I	I
Aprobar excepciones de presupuesto	I	C	I	A	I	I	I	I	I	I
Reportar tendencias de costos a liderazgo	I	I	I	I	I	A/R	I	I	I	I

5.10 Onboarding y Soporte

Responsable Aprobador Consultado Informado

Actividad	DEV	TL	QA	PO	ARQ	PE	SRE	SEC	DBA	COMA
Onboarding de nuevo developer	C	A/R	I	I	I	C	I	C	I	I
Onboarding de nuevo producto a HERA	C	C	I	C	C	A/R	I	C	C	C
Soporte L1 (chat #hera-soporte)	I	I	I	I	I	A/R	I	I	I	I
Soporte L2 (tickets BMC)	I	I	I	I	I	A/R	C	C	C	I
Mantener documentación HERA	C	C	I	I	C	A/R	C	C	I	I
Formación del equipo en herramientas HERA	C	C	C	I	C	A/R	C	C	I	I

Cómo leer la matriz RACI

Para cada actividad, identifica quién es A (Accountable): solo hay UNO. Es la persona que rinde cuentas. R (Responsible) son los que ejecutan, pueden ser varios. C son consultados antes de decidir. I son notificados después.

Si una actividad NO está en esta matriz, escala al Comité de Arquitectura (COMA) para definirla.

---

6. Reglas de Incorporación de Nuevos Servicios

Cualquier servicio que entra al ecosistema HERA debe seguir un proceso formal de incorporación. Esto previene servicios “fantasma” sin clasificación, sin dueño ni sin gobernanza.

Proceso de incorporación (8 pasos)

Paso	Actividad	Responsable	Entregable
1	Solicitud inicial vía ticket BMC	Tech Lead del producto	Ticket con nombre, dominio, propósito de negocio
2	Revisión arquitectónica	Arquitecto	Aprobación o feedback de cambios
3	Asignación de categoría (1 de 13)	Tech Lead + Arquitecto	Categoría declarada en service-manifest
4	Creación del repo en GitLab con estructura HERA	Platform Engineer	Repo creado, naming validado
5	Configuración del Golden Pipeline	Developer	.gitlab-ci.yml desde template
6	Definición del service-manifest.yml	Tech Lead	Manifest con owner, dependencias, SLO, criticidad
7	Aprovisionamiento de namespace + infraestructura base	Platform Engineer	Namespace en GKE, secretos, monitoring
8	Validación de homologación HERA-compliant	Platform Engineer + Security	Lista de verificación aprobada

SLA del proceso

Tipo de servicio	SLA esperado
Servicio estándar (categoría existente, sin excepciones)	5 días hábiles
Servicio con excepción menor (justificación documentada)	10 días hábiles
Servicio con excepción mayor (requiere aprobación COMA)	15 días hábiles
Servicio que requiere nueva categoría	30 días hábiles + decisión del Comité

Quién puede iniciar la incorporación

Solicitante	¿Permitido?
Tech Lead de un producto existente	✅ Sí, directamente
Developer	⚠️ Solo con aprobación previa de su Tech Lead
Partner de Desarrollo (externo)	⚠️ Solo a través del Tech Lead interno responsable
PO / Negocio	❌ Debe canalizarse vía Tech Lead técnico
Cualquier otro rol	❌ Se canaliza al Tech Lead correspondiente

Anti-pattern: “Servicio en la sombra”

Un servicio en la sombra es aquel que existe en GCP pero NO siguió el proceso de incorporación. No tiene manifest, no tiene categoría, no tiene owner formal. Estos son los riesgos:

1. No tiene observabilidad — incidentes no se detectan
2. No tiene SLO — no hay compromiso de disponibilidad
3. No pasa validaciones automatizadas (Quality Gates) — vulnerabilidades sin remediar
4. No tiene etiquetado de costos — el gasto no se asigna a nadie
5. No tiene cumplimiento (compliance) — auditorías externas lo señalan
6. No tiene plan de recuperación — si falla, nadie sabe restaurarlo

Política HERA: Servicios en la sombra detectados se reportan al Comité de Arquitectura, se notifica al área dueña, y tienen 30 días para regularizarse o ser decomisionados.

---

7. Criterios de Homologación HERA-compliant

Un servicio se considera HERA-compliant cuando cumple todos los siguientes criterios. Estos criterios son revisados durante la incorporación (paso 8) y auditados periódicamente.

Lista de verificación de Homologación HERA-compliant

Identidad y clasificación

• Tiene un service-manifest.yml válido
• Está asignado a una de las 13 categorías oficiales de HERA
• El repositorio sigue la convención de nombres <tipo>-<detalle>
• Vive en la jerarquía correcta de GitLab (grupo-herdez/products/{dominio}/{producto}/{version}/)
• Tiene un dueño declarado (Tech Lead identificable)
• Tiene criticidad definida (critical, high, medium, low)

Build y CI/CD

• Usa el Golden Pipeline de HERA (no pipeline personalizado sin justificación)
• El pipeline pasa todos los umbrales de calidad (Quality Gates) sin excepciones no documentadas
• SAST (SonarQube) sin hallazgos Críticos
• SCA (Docker Scout) sin vulnerabilidades Críticas/Altas en dependencias
• Detección de secretos (TruffleHog) sin hallazgos
• Conventional Commits aplicado

Artefactos

• Imagen Docker construida desde Golden Image aprobada
• Imagen versionada con <repo>:<semver>-<short-sha>
• Imagen firmada con Cosign (para PRD)
• SBOM generado y adjunto a la imagen
• Imagen publicada en Artifact Registry corporativo

Infraestructura

• Toda la infraestructura del servicio está definida en Terraform
• No tiene cambios manuales en consola GCP (validado por detección de desviaciones/drift)
• Usa Workload Identity (no llaves JSON de cuentas de servicio)
• Vive en el namespace correcto del producto (el nombre del namespace coincide exactamente con el nombre del producto, sin prefijos)
• Tiene políticas de red (Network Policies) explícitas (no default-allow)
• Etiquetado obligatorio completo (5 etiquetas mínimas)

Observabilidad

• Emite logs estructurados en JSON
• Expone métricas RED (Request, Error, Duration)
• Implementa validaciones de salud (liveness + readiness probes)
• Tiene tablero (dashboard) configurado
• Tiene al menos 1 SLO definido y midiéndose
• Tiene alertas configuradas con umbrales correctos

Seguridad

• Cumple el modelo Zero Trust (mTLS donde aplique)
• Secretos en GCP Secret Manager, nunca en código
• Cumple políticas de Cloud Governance (regiones, IPs, etc.)
• MFA habilitado para los responsables técnicos del servicio
• Revisiones de acceso periódicas completadas al día

Documentación

• Tiene README.md completo con: propósito, cómo ejecutar localmente, cómo desplegar, cómo contactar al equipo
• Tiene especificación OpenAPI publicada (si es API)
• Tiene manual operativo (runbook) (si es servicio crítico o alto)
• Aparece en el catálogo de servicios central de HERA

Niveles de homologación

Para reflejar la realidad operacional (no todo se cumple desde día 1), HERA define 3 niveles de homologación:

Nivel	Nombre	Criterios cumplidos	Implicaciones
Bronze	Mínimo viable	Identidad + Build/CI + Infraestructura básica	Permitido en DEV/QA, NO en PRD
Silver	Listo para producción	+ Artefactos + Observabilidad + Seguridad	Permitido en PRD con criticidad medium o menor
Gold	Grado empresarial	+ Documentación completa + SLOs maduros + Catálogo de Servicios	Permitido para servicios critical y high

Validación periódica

Los criterios de homologación se validan automáticamente mediante:

Herramienta	Frecuencia	Qué valida
Pipeline de validación de manifiesto	Cada commit	Estructura del service-manifest.yml
Políticas OPA en CI	Cada MR de infraestructura	Cloud Governance, etiquetado
Cloud Asset Inventory	Diario	Desviaciones de Terraform, recursos huérfanos
Escáner de Catálogo de Servicios	Semanal	Servicios en la sombra
Tarea de auditoría de cumplimiento	Mensual	Reporte ejecutivo de homologación por producto

Servicios no homologados

Un servicio que no cumple el nivel Silver mínimo NO puede desplegarse a producción. Esto se asegura automáticamente vía políticas de Kyverno en GKE: pods con imágenes que no cumplen criterios son rechazados al momento de la admisión.

---

8. Comité de Arquitectura HERA (COMA)

El Comité de Arquitectura HERA es la mesa de gobierno técnico que:

• Aprueba decisiones arquitectónicas mayores (nuevos patrones, herramientas, categorías de servicio)
• Resuelve disputas entre equipos sobre interpretación del modelo HERA
• Aprueba excepciones al gobierno (servicios fuera del estándar)
• Mantiene el roadmap evolutivo de HERA

Composición

Rol	Voto
Líder de Arquitectura (presidente)	Sí
Líder de Plataforma (PE/DevOps)	Sí
Líder de Seguridad	Sí
Líder de SRE	Sí
Líder de Datos	Sí (cuando aplique)
Tech Leads invitados (rotación)	Consultivo
PO / Negocio invitado	Consultivo

Cadencia

• Reunión mensual ordinaria (revisión de estado, decisiones programadas)
• Reunión extraordinaria cuando se requiere aprobación urgente (24-48h)
• Workshop trimestral de evolución del modelo

Decisiones registradas

Toda decisión del Comité se registra en el Decision Log como DEC-XXX con:

• Contexto
• Opciones evaluadas
• Decisión tomada
• Razonamiento
• Consecuencias

---

9. Gobernanza del propio Modelo de Gobierno

Este documento también está bajo gobierno. No se modifica ad-hoc.

Cómo se modifica este documento

Tipo de cambio	Aprobación requerida
Corrección menor (typo, link roto, claridad)	Merge Request + 1 reviewer del equipo HERA
Cambio en RACI (mover responsabilidades entre roles)	Merge Request + aprobación del Comité de Arquitectura
Cambio de principios rectores	Workshop del Comité + Approve formal
Cambio de criterios de homologación	Comité + Notificación a todos los Tech Leads (30 días anticipación)
Nueva sección	Comité de Arquitectura

Frecuencia de revisión

• Revisión menor cuatrimestral — verificación de claridad y vigencia
• Revisión mayor anual — actualización de principios, RACI, criterios

---

10. Cómo se conecta este documento con el resto de HERA

Tema	Documento detallado
Roles individuales en detalle	Roles y Responsabilidades
Responsabilidades por fase del SDLC	Responsabilidad Compartida
Marco ALM/SDLC	Marco ALM/SDLC
13 categorías de servicios	Clasificación de Servicios
Principios cloud governance	Cloud Governance
Estructura de repositorios	Estructura de Repositorios

Documento en evolución

Este Modelo de Gobierno HERA se actualiza con la madurez operacional de Grupo Herdez. Refleja el estado del modelo en 2026 y se revisa conforme la organización madura. Las sugerencias de cambio son bienvenidas a través del proceso documentado en la sección 9.