Una Quality Platform es un producto, no un repositorio de utilidades

Aviso. Nexo Finanzas es ficticio. No se ejecutó ninguna plataforma ni pipeline. Las métricas de adopción son ilustrativas. Este contenido no afirma haber operado una plataforma interna con usuarios reales.

Promesa del artículo. Al terminar vas a poder distinguir una plataforma de una librería compartida —una distinción con consecuencias operativas, no semánticas—, identificar a los usuarios reales de tu plataforma, y saber por qué construirla demasiado pronto es peor que no construirla.

El repositorio que se llama plataforma

Casi toda organización tiene un repositorio llamado test-commons, qa-utils o automation-framework. Contiene:

• Un cliente HTTP con algunos helpers.
• Un BaseTest del que todo hereda.
• Utilidades de datos de prueba.
• Configuración de reportes.
• Algo de Selenium.

Es útil. La gente lo usa. Y no es una plataforma. Es una librería compartida con aspiraciones, y la diferencia se nota exactamente en cinco momentos:

La diferencia no es la calidad del código. Es que una plataforma tiene usuarios que pueden irse, y eso lo cambia todo.

Tesis del capítulo. Una Quality Platform no es un repositorio gigante de utilidades. Es un producto interno con usuarios, contratos, soporte, límites y resultados medibles, que reduce la carga cognitiva sin quitar autonomía.

La condición previa que casi nadie respeta

Antes de seguir, la advertencia que da sentido a la ubicación de este capítulo en la serie:

No se puede plataformizar lo que todavía no sabés hacer a mano.

Si nunca implementaste un outbox, tu template de servicio Java no va a tenerlo, o lo va a tener mal. Si nunca depuraste un canary, tu golden path de despliegue va a omitir la instrumentación por versión. Y peor: la abstracción va a esconder el error, de modo que veinte equipos van a heredar tu ignorancia sin poder verla.

Las plataformas prematuras tienen una firma reconocible: cubren perfectamente el caso que su autor conocía y son inflexibles con todos los demás. La reacción de los equipos es forkear, y en seis meses hay cinco versiones divergentes del “framework compartido” y nadie sabe cuál es la buena.

El orden correcto: recorrer el camino a mano, en un proyecto real, dos o tres veces. Descubrir dónde duele. Y recién entonces empaquetar la parte que duele.

Los siete capítulos anteriores de esta serie son ese camino.

Quiénes son tus usuarios

Una plataforma sin personas identificadas construye para un usuario promedio que no existe.

En un contexto ficticio de Nexo Finanzas, las personas y su job-to-be-done:

Fijate que la persona más importante no es el dev de producto: es el on-call. Porque es la única que interactúa con la plataforma en el peor momento posible, y su experiencia determina si el equipo confía en ella.

Una plataforma que en un incidente muestra un stack trace de sus propias internas ha fallado en su función principal, por muy elegante que sea su API.

De acá sale un principio de diseño que vale más que cualquier feature:

La abstracción no puede esconder cómo depurar. Si tu componente envuelve un cliente HTTP, cuando falla tiene que decir cuál fue el request y cuál la respuesta. Si envuelve el pipeline, tiene que decir qué comando corrió. Una capa que oculta el comando subyacente convierte cada incidente en una investigación arqueológica del código de la plataforma.

Carga cognitiva, no autonomía

La justificación honesta de una plataforma es reducir la carga cognitiva: el dev de producto no debería tener que saber cómo se configura la firma de artefactos para poder entregar una feature.

Pero hay una tentación adyacente, y es la que mata plataformas: reducir la autonomía. “Como no queremos que piensen en esto, no los dejamos tocarlo.”

La diferencia se ve en una pregunta: ¿qué pasa cuando un equipo necesita algo que la plataforma no contempla?

El escape hatch —una forma documentada, soportada y no vergonzosa de salirse del camino— es lo que hace sostenible a una plataforma. Y tiene un beneficio secundario: cada uso del escape hatch es una señal de producto. Si tres equipos lo usan para lo mismo, encontraste la próxima capability.

Una plataforma sin escape hatch no recibe esa señal. Recibe forks silenciosos.

El catálogo de capacidades

Una plataforma es un conjunto de capacidades, no un monolito. Cada una se adopta por separado.

Y cada entrada del catálogo declara cinco cosas. Si le falta una, no está lista para que alguien dependa de ella.

# catalog/ephemeral-environments.yaml — ficticio.
capability: ephemeral-environments
description: >
  Provisiona un entorno aislado (app + PostgreSQL + broker) por pull request,
  con datos sinteticos sembrados y TTL automatico.

owner: "@ficticio-quality-platform"        # una persona o un equipo. NUNCA "todos"
support_channel: "#nexo-quality-platform"
version: "2.3.0"

# El SLO INTERNO: la promesa que le hacemos a nuestros usuarios.
slo:
  provisioning_time_p95: "< 4 minutos"
  availability: "99% en horario laboral"
  # Y lo que NO prometemos, que es igual de importante:
  not_promised:
    - "Disponibilidad fuera de horario laboral"
    - "Retencion de datos entre corridas"
    - "Paridad exacta con produccion"

escape_hatch:
  description: "Levantar el entorno con docker compose directamente"
  documentation: "docs/golden-paths/entorno-local-sin-plataforma.md"
  supported: true                          # NO es una via de escape vergonzosa

deprecation_policy: "docs/deprecations/policy.md"

Tres campos merecen defensa:

• not_promised es tan importante como el SLO. Una plataforma que no declara sus límites recibe expectativas que no puede cumplir, y las incumple en silencio. La lista de lo que no prometés es lo que hace creíble lo que sí prometés.
• escape_hatch.supported: true. No es una nota al pie diciendo “si esto no te sirve, arreglátelas”. Es una ruta documentada y mantenida. La plataforma también prueba el escape hatch.
• owner nunca es “el equipo de calidad”. Es una persona o un equipo con un canal. Una capability sin dueño es una capability muerta que todavía no lo sabe.

Producto versus framework: el test de las tres preguntas

Para saber si lo que estás construyendo es un producto o una librería con pretensiones:

1. ¿Podés nombrar a tus usuarios y su job-to-be-done? Si la respuesta es “los equipos”, no.
2. ¿Existe una forma de no usarla que no sea forkear? Si no, tus usuarios no eligen: obedecen. Y la adopción que medís no significa nada.
3. ¿Sabés cuándo la plataforma es la que falló? Si el on-call no puede distinguir un fallo de plataforma de un fallo de producto, no tenés observabilidad de tu producto.

La tercera pregunta genera la métrica más valiosa del capítulo: fallos de plataforma versus fallos de producto. Requiere que cada fallo se clasifique, y esa clasificación es lo que te dice si estás mejorando.

Un pipeline que falla porque el runner no pudo bajar una imagen es un fallo de plataforma, y el equipo de producto no puede hacer nada. Si el 30 % de los fallos son de plataforma, la adopción va a caer y ninguna presentación lo va a evitar.

El ciclo del producto interno

La caja Improve or deprecate es la que casi nunca se cierra. Las plataformas acumulan capacidades y no retiran ninguna, porque retirar es incómodo y “alguien la debe estar usando”.

Una capability que nadie adopta después de un plazo razonable no debe mejorarse: debe retirarse. El esfuerzo de mantenerla es esfuerzo que no está en la que sí se usa. El artículo 3 trata cómo hacerlo sin castigar a nadie.

Empezar por dos, no por diez

El error de alcance más común y más caro: intentar cubrir todos los casos de todos los equipos desde el día uno.

La restricción que recomiendo, y que el prompt de diseño de proyectos también impone: exactamente dos golden paths.

Para nexo-quality-developer-platform (ficticio):

1. “De cero a un servicio Java con pipeline de calidad.” Template de repositorio con build, tests, SBOM, escaneo, reportes y ADRs. Cubre al dev de producto.
2. “De cero a evidencia de un journey.” Componente de automatización con reporte normalizado y publicación de evidencia. Cubre al SDET.

Y un escape hatch documentado para cada uno.

Dos, no diez. Porque:

• Dos se pueden mantener, versionar y probar bien.
• Dos generan feedback rápido y real.
• Con diez, ninguno está terminado, y el equipo aprende que la plataforma no es confiable. Recuperar esa confianza cuesta años.

Un tercer golden path solo se agrega cuando los dos primeros tienen adopción voluntaria sostenida y su costo de mantenimiento es conocido.

Tenancy y seguridad

Una plataforma es un objetivo interesante. Corre código de N equipos, con credenciales, contra infraestructura compartida.

Tres reglas que se derivan directamente del threat model del pipeline:

1. Un componente de la plataforma no debe requerir más permisos de los que necesita. Un reporter que sube resultados no necesita credenciales del registry.
2. El aislamiento entre tenants es un requisito, no una propiedad emergente. Si dos PRs de equipos distintos comparten un namespace, comparten estado. Y a veces, secretos.
3. La plataforma es un vector de supply chain. Un template de repositorio comprometido se propaga a todos los repos creados con él. Los componentes de la plataforma se firman y se verifican, igual que cualquier artefacto.

La tercera es la que se subestima. Tu plataforma es una dependencia de todos tus repositorios. Merece el mismo rigor que cualquier dependencia de terceros —más, porque nadie la audita desde afuera.

Anti-patrones

• Plataformizar antes de haber recorrido el camino. Consecuencia: codificás tu ignorancia y la repartís bajo una abstracción que impide verla. Alternativa: hacerlo a mano dos o tres veces.
• Mandato central sin feedback. Consecuencia: medís adopción forzada, que no informa nada. Alternativa: adopción voluntaria como métrica.
• One-size-fits-all sin escape hatch. Consecuencia: forks silenciosos. Alternativa: escape hatch documentado y soportado, que además es tu mejor señal de producto.
• Plataforma sin owner ni canal de soporte. Consecuencia: nadie responde a las 3 AM. Alternativa: owner nominal por capability.
• Abstracciones que esconden cómo depurar. Consecuencia: cada incidente es arqueología del código de la plataforma. Alternativa: la capa muestra el comando, el request y la respuesta subyacentes.
• SLO sin not_promised. Consecuencia: incumplís expectativas que nunca aceptaste. Alternativa: declarar los límites.
• Diez golden paths. Consecuencia: ninguno terminado; la confianza se pierde y tarda años en volver. Alternativa: dos.
• No poder distinguir fallo de plataforma de fallo de producto. Consecuencia: no sabés si estás mejorando. Alternativa: clasificación obligatoria de fallos.
• No retirar nunca una capability. Consecuencia: el mantenimiento de lo muerto le roba tiempo a lo vivo. Alternativa: cerrar el ciclo con deprecación.
• Tratar la plataforma como confiable por ser interna. Consecuencia: es una dependencia de todos tus repos, sin auditoría externa. Alternativa: firmarla y verificarla.

Qué publicar en GitHub

catalog/                              # una capability por archivo, con owner y not_promised
templates/java-service/
templates/test-automation/
components/pipelines/
components/reporting/
docs/golden-paths/                    # DOS, y sus escape hatches
docs/platform-slos/                   # con lo que NO se promete
docs/deprecations/policy.md
docs/adr/ADR-001-que-centralizar.md   # y qué dejar deliberadamente al producto
examples/

docs/adr/ADR-001-que-centralizar.md es el documento más difícil y más valioso. Debe contener una lista explícita de lo que la plataforma decide NO hacer: la estrategia de pruebas de cada equipo, la definición de sus riesgos, la elección de sus assertions. Centralizar eso es quitar autonomía, y una plataforma que lo hace deja de tener usuarios y pasa a tener súbditos.

Qué aprendimos / próximos pasos

• La diferencia entre plataforma y librería compartida no es técnica: es que la plataforma tiene usuarios que pueden irse.
• No se plataformiza lo que no se sabe hacer a mano. Esa es la razón por la que este capítulo va casi al final.
• El usuario más importante es el on-call, no el dev de producto.
• La abstracción no puede esconder cómo depurar.
• El escape hatch es lo que hace sostenible una plataforma, y es tu mejor señal de producto.
• not_promised hace creíble al SLO.
• Empezá por dos golden paths.

Siguiente: Golden paths, escape hatches y contrato de evidencia.

Checklist final

• Podés nombrar tus personas y su job-to-be-done.
• Recorriste el camino a mano antes de plataformizarlo.
• Cada capability tiene owner nominal y canal de soporte.
• Cada capability declara su SLO y su not_promised.
• Cada golden path tiene un escape hatch documentado y soportado.
• La plataforma prueba también sus escape hatches.
• Ningún componente esconde el comando, request o respuesta subyacente.
• Los fallos se clasifican en “de plataforma” y “de producto”.
• Hay exactamente dos golden paths.
• Existe un ADR de qué no se centraliza.
• Los componentes de la plataforma se firman y se verifican.
• El aislamiento entre tenants es explícito, no emergente.
• Existe una política de deprecación antes de la primera deprecación.

Fuentes (consultadas 2026-07-10)

• SLSA v1.2 — la plataforma es una dependencia; se firma y se verifica.
• OpenTelemetry Documentation — para distinguir fallo de plataforma de fallo de producto.
• OpenFeature — spec 0.8.0 (pre-1.0), SDK de Java GA. Ver verificación de fuentes.
• Documentación primaria de Kubernetes y del CI que uses.
• Sobre “platform engineering” como práctica: es un campo en evolución, no una metodología cerrada. Verificá y citá las fuentes originales que uses; esta serie no las presenta como canon.
• Verificación de fuentes de la serie