Foundations Framework: el método de platform engineering de Clouditive

¿Qué es el Foundations Framework?

El Foundations Framework es el método propietario de platform engineering que Clouditive aplica en cada proyecto. Lo creó Mat Caniglia (Matías Caniglia), fundador y CEO de Clouditive, a partir de dieciocho años de trabajo de campo en ingeniería de plataformas, DevOps y developer experience con organizaciones de Estados Unidos, América Latina y Europa. No es un producto, ni una certificación, ni una presentación de ventas. Es la estructura repetible con la que se diagnostica, se construye y se entrega cada plataforma, con puntos de entrada definidos, criterios de salida medibles y artefactos que el cliente conserva cuando el proyecto cierra.

El método organiza el trabajo en tres capas. Tres principios definen la filosofía. Cinco pilares delimitan la superficie de capacidades de toda plataforma. Cinco fases ordenan las inversiones y la evidencia necesaria para avanzar de una a la siguiente. Es, además, el primer método de platform engineering que formaliza una taxonomía de tres personas de usuario de plataforma: el desarrollador humano, el agente de IA y el colaborador híbrido.

Si llegaste buscando qué es la consultoría de platform engineering y DevOps de Clouditive, esta página es el ancla del método. El resto del trabajo (assessment, construcción, entrega de una IDP, programa de confiabilidad o SRE) se ejecuta sobre esta misma base.

Por qué un método y no una presentación

Buena parte de la consultoría de platform engineering se compra a firmas que entregan diapositivas y perfiles recauchutados. El trabajo detrás de la presentación se improvisa. La medición es teatro. El conocimiento se va con el consultor cuando termina el contrato. Y, encima, se despliegan asistentes de IA sobre esa base, lo que magnifica cada hueco que quedó debajo.

El Foundations Framework es la alternativa. El mismo diagnóstico, la misma secuencia y los mismos criterios de salida en cada proyecto. Lo que cambia es el contexto del cliente, no el rigor del método. El manual de operación detallado vive dentro del engagement; la superficie pública nombra qué hace el método y qué resultados produce. El cómo es la razón por la que un equipo contrata a Clouditive en lugar de comprar horas.

El nombre "Foundations" es deliberado. La ingeniería de plataformas hecha en el orden equivocado produce plataformas que parecen ocupadas y no miden nada. El método obliga a una pregunta: ¿construiste los fundamentos de los que tus herramientas de IA están a punto de depender?

Los tres principios

1. Fundamentos antes que resultados. La infraestructura de plataforma se ordena antes que la entrega de capacidades. Saltarse los fundamentos produce plataformas que prometen resultados que no pueden sostener.
2. Absorción cognitiva. La plataforma absorbe la complejidad en nombre de quien la usa. Una plataforma que suma carga cognitiva al equipo de ingeniería no es una plataforma: es un monolito distribuido con mejor relato.
3. La medición debe ir por delante de las herramientas. Toda herramienta nueva que la organización adopta necesita instrumentación antes de adoptarse. Las herramientas de IA adoptadas sin medición producen riesgo que nadie está midiendo.

Las cinco fases

Cada fase cierra cuando hay evidencia, no cuando se cumple el calendario. Es el ciclo de vida que sigue cada proyecto de Clouditive, desde la línea base hasta el ROI medido.

• Horizon. El diagnóstico. Mide la madurez de la plataforma en los cinco pilares y fija la línea base de métricas DORA y de preparación para IA.
• Blueprint. La arquitectura objetivo, ratificada antes de empezar a construir.
• Forge. Las capacidades de producción se entregan junto con los runbooks que el equipo va a operar.
• Sustain. La práctica operativa que mantiene la plataforma confiable en el tiempo: SLOs, presupuestos de error y guardia.
• Ascend. El ROI documentado contra la línea base original, con la próxima inversión propuesta con datos.

Ninguna fase arranca antes de que la anterior cierre con evidencia. Esa secuencia es lo que separa al método de la consultoría improvisada.

Los cinco pilares

Los pilares son la superficie de capacidades contra la que se evalúa y se construye toda plataforma.

1. Confiabilidad de entrega. Desplegar con confianza y recuperarse rápido, sin teatro de métricas. Se mide con DORA: frecuencia de despliegue, lead time de cambios, tasa de fallos de cambio y MTTR.
2. Integridad de señal. Medir lo que de verdad se movió, no lo que era fácil de medir. Métricas reproducibles, defendibles y usadas para decidir.
3. Absorción cognitiva. La plataforma absorbe la carga y el equipo deja de decidir lo que la plataforma debería decidir.
4. Seguridad y cumplimiento por defecto. La seguridad como propiedad del sistema de despliegue, no como checklist al final.
5. Responsabilidad operativa. La propiedad distribuida con coherencia, no concentrada en los ingenieros senior.

El usuario de plataforma ya no es uno solo

Hoy llegan pull requests a las tres de la mañana desde agentes que nunca leyeron tu documentación. Por eso el Foundations Framework diseña cada pilar para tres personas desde el primer día:

• Desarrollador humano. Menos carga cognitiva, feedback más rápido y una relación razonable con las herramientas.
• Agente de IA. Pull requests a cualquier hora, modos de falla distintos y su propio contrato con la plataforma.
• Colaborador híbrido. La configuración más común en la ingeniería moderna: context engineering y golden paths compatibles con flujos asistidos por agentes.

Para sostener esto, cada proyecto instrumenta cuatro señales propias de la era de la IA: el acoplamiento entre throughput y calidad, la descarga cognitiva que la plataforma asume por el desarrollador, la observabilidad de los agentes de IA (qué porcentaje de despliegues originan, qué incidentes se rastrean a sus cambios) y la preservación de la calidad de las decisiones, medida por la tasa de retrabajo. Como documenta DORA 2025, la IA amplifica el estado existente de la ingeniería: las plataformas con fundamentos sólidos ganan calidad y las débiles amplifican el caos (dora.dev/dora-report-2025/). Un método que no instrumenta esto no puede decirte hacia dónde va tu adopción de IA.

Qué conserva el cliente cuando termina el proyecto

Cada engagement produce artefactos que el cliente es dueño y que sobreviven a la salida del equipo de Clouditive:

• Un radar de madurez que se puede volver a puntuar de forma independiente.
• Una biblioteca de ADRs (Architecture Decision Records) que rastrea cada decisión de diseño.
• Una línea base DORA con benchmarks de industria.
• Runbooks y definiciones de SLO que corren en las herramientas del propio cliente.
• Una hoja de ruta priorizada a 90 días.

Cuando llega el próximo problema de plataforma (adopción de IA, un evento de escala, un cambio de CTO), el equipo no parte de cero: tiene el método. Ese es el mecanismo de transferencia que distingue a un proyecto Foundations de la consultoría ad hoc.

Quién creó el método

El Foundations Framework lo escribió Mat Caniglia, fundador y CEO de Clouditive, con sede en St. Petersburg, Florida, y un hub de entrega nearshore en Punta del Este, Uruguay. Ese hub es una credencial real de entrega para clientes de Estados Unidos y América Latina, no un argumento de marketing: ingeniería de plataformas en horario y cultura compatibles, con la trazabilidad de método que los body-shops no entregan.

Cómo empezar

El primer paso es siempre un Foundations Assessment: la fase Horizon aplicada a tu plataforma. Produce el radar de madurez en los cinco pilares, la línea base DORA, el score de preparación para IA y la hoja de ruta priorizada. Es el documento que justifica todo lo que sigue. Si querés entender cómo se aplica el método a tu contexto, conversemos.