Modelo Operativo HERA

HERA es la plataforma corporativa de Application Lifecycle Management (ALM) de Grupo Herdez. Centraliza, automatiza y gobierna el ciclo de vida completo del software — desde la idea hasta la produccion — bajo una cultura unificada de DevSecOps, Zero Trust y FinOps.

Esta seccion es el hub central del modelo operativo y de gobernanza: gobierno formal, roles, responsabilidades, ciclo de vida, ecosistema, naming, namespaces, ambientes, ownership y reglas de operacion.

Documentos centrales del Modelo Operativo

Documento	Propósito	Audiencia
Modelo de Gobierno HERA	Documento maestro de gobierno: propósito, alcance, principios rectores, RACI, reglas de incorporación, criterios de homologación	Liderazgo, auditores, arquitectos
Roles y Responsabilidades	Definición de cada rol del ecosistema HERA	Todos
Responsabilidad Compartida	Quién hace qué en cada fase del SDLC	Todos
Ciclo de Vida del Software	Las 8 fases del SDLC en HERA	Todos
Marco ALM/SDLC	Cómo HERA implementa ALM	Arquitectos, líderes
Ecosistema de Herramientas	Las herramientas que componen HERA	Todos

El Problema que Resolvemos

Antes de HERA, los equipos enfrentaban estos problemas:

Despliegues sin estandarización ni control
Costos elevados por infraestructura sobredimensionada
Vulnerabilidades de seguridad por secretos expuestos y falta de análisis
Pérdida de conocimiento por falta de documentación
Equipos en silos sin reglas claras de colaboración

La Solución HERA

HERA aborda estos problemas mediante:

Estandarización de flujos CI/CD y herramientas
Automatización de pruebas, seguridad y despliegues
Gobierno centralizado de la infraestructura, seguridad y costos
Medición del rendimiento a través de métricas DORA
Reglas claras de operación, incorporación y homologación

Los 10 principios rectores que guían las decisiones técnicas y operativas en HERA — junto con su implicancia práctica — están formalmente definidos en Modelo de Gobierno HERA — Principios Rectores.

Componentes de Gobierno y Estandarización

Esta sección consolida dónde está documentado cada componente del gobierno operativo. No duplica el contenido — es un mapa de descubrimiento.

Estándares de Naming

Aspecto	Documento
Naming de repositorios (`<tipo>-<detalle>`)	Clasificación de Servicios — Convención de Naming
Naming de servicios por categoría	Estructura de Repositorios
Naming de Project Keys SonarQube	Estructura de Repositorios — Convención de Project Key
Naming de tags de imágenes Docker	Golden Pipeline — convenio `IMAGE_TAG`
Conventional Commits	Conventional Commits
Reglas de tagging de recursos GCP	Estándares de Tagging

Convenciones de Namespaces

Aspecto	Documento
Namespace por producto en GKE (el nombre del namespace coincide con el nombre del producto, sin prefijos)	Clasificación de Servicios — K8s Namespace
Permanencia del namespace cross-versión	Estructura de Repositorios
Network Policies por namespace	GKE — Network Policies
RBAC por namespace	Gestión de Identidades

Organización por Ambientes (DEV, QA, PRD)

Aspecto	Documento
Estructura de ambientes y SLA por ambiente	Infraestructura — Estructura de Ambientes
GKE por ambiente (Autopilot vs Standard)	GKE — Especificaciones por Ambiente
Promoción entre ambientes (build once, deploy many)	GitLab Workflow — Flujo DEV → QA → PRD
Estrategias de despliegue por ambiente	GitLab Workflow

Modelo de Ownership

Nivel de ownership	Documento
Ownership de servicio (Tech Lead + equipo)	Roles
Ownership de datos (Domain Service como dueño)	Principio de Data Ownership: cada dominio es fuente de verdad de sus datos
Ownership de producto (Product Owner)	Responsabilidad Compartida
Ownership de dominio (Tech Lead del dominio)	Estructura de Repositorios
Ownership de plataforma (equipo HERA)	Modelo de Gobierno HERA
Service Catalog Metadata (manifest obligatorio)	Registro obligatorio en catálogo HERA con metadata: dueño, criticidad, dependencias, SLO

Estandarización de Repositorios, Pipelines y Despliegues

Aspecto	Documento
Taxonomía de repositorios GitLab	Estructura de Repositorios
CI/CD + branching strategy	GitLab Workflow
Estrategias de despliegue (rolling, blue/green, canary)	GitLab Workflow
Image signing y SBOM	SCA (Docker Scout)

Separación de Responsabilidades por Área

Dónde encontrar formalmente quién es responsable de qué en HERA:

Necesito entender…	Documento de referencia
Frontera operativa entre los 3 bloques (Producto, Plataforma, Gobierno Transversal)	Responsabilidad Compartida
Matriz RACI formal con 75+ actividades distribuidas en 10 áreas (diseño, desarrollo, CI/CD, infraestructura, despliegues, SRE, seguridad, compliance, FinOps, soporte)	Modelo de Gobierno HERA — Modelo RACI
Definición de cada rol del ecosistema (DEV, TL, QA, PO, ARQ, PE, SRE, SEC, DBA, COMA) y a qué equipo pertenece	Roles y Responsabilidades
Canales de soporte en 3 niveles (self-service → Google Chat → tickets BMC)	Contacto y Canales
Quién asume la función de delivery en HERA (TL + PO + PE; no existe rol formal “Delivery Manager”)	Responsabilidad Compartida · Modelo de Gobierno — 5.5 Despliegues y Releases

Reglas Operacionales Clave

Reglas de incorporación de nuevos servicios

Todo nuevo servicio sigue un proceso formal de 8 pasos. Ver Modelo de Gobierno — Reglas de Incorporación.

Criterios de homologación HERA-compliant

Tres niveles de homologación: Bronze, Silver, Gold. Solo Silver o superior puede desplegarse a PRD. Ver Criterios de Homologación.

Comité de Arquitectura HERA (COMA)

Mesa de gobierno técnico para decisiones mayores. Reunión mensual ordinaria. Ver Comité de Arquitectura.

Preguntas Frecuentes del Modelo Operativo

¿Dónde encuentro X?

Si necesito…	Voy a…
Saber qué rol tengo y qué se espera de mí	Roles y Responsabilidades
Entender el modelo formal de gobierno	Modelo de Gobierno HERA
Saber quién es responsable formalmente de algo	Modelo RACI
Crear un nuevo servicio en HERA	Reglas de Incorporación
Validar si mi servicio cumple los estándares	Criterios de Homologación
Entender en qué fase del SDLC estoy	Ciclo de Vida del Software
Saber qué herramientas usa HERA	Ecosistema de Herramientas