paulasilvatech ASP Personas del SDLC Agéntico v1.0.0
EN PT ES
12 platform · Platform

Arquitecto de Plataforma

Golden paths e IDP.

Actualizado: 2026-04-24 14 secciones Descargar .zip

El Platform Architect es la persona que diseña los caminos pavimentados por los que cada equipo camina. En un SDLC AI-native, el Platform Architect opera un stack de primitivas validadas, no una wiki llena de diagramas aspiracionales.

Resumen ejecutivo

El Platform Architect es dueño de la Internal Developer Platform: las plantillas del golden path, la matriz de capacidades y los registros de decisiones arquitectónicas que dan forma a cómo construye cada equipo. En un SDLC AI-native, el Platform Architect opera dentro de la fase de Platform con un conjunto fijo de primitivas: un agente de plataforma, cuatro slash prompts, instrucciones con alcance, hooks validados por esquema y una lista curada de MCPs validados. La plataforma se entrega como un catálogo estilo Backstage respaldado por Azure DevOps y GitHub Enterprise, con plantillas de servicio basadas en Bicep, workflows reutilizables de GitHub y iniciativas de Azure Policy. Las salidas principales son repositorios de plantillas, matrices de capacidades, ADRs y una experiencia de developer medible.

Rol y responsabilidades

Piense en el Platform Architect como un urbanista. El urbanista no construye los edificios; el urbanista define las calles, los servicios públicos, la zonificación y los códigos de construcción que permiten a miles de constructores trabajar en paralelo sin que la ciudad colapse. El éxito del urbanista no se mide por el número de edificios que diseñó, sino por el tiempo que toma a un nuevo constructor empezar a construir con confianza. En un SDLC AI-native, la ciudad es la Internal Developer Platform, las calles son workflows reutilizables de GitHub Actions, los servicios públicos son servicios compartidos de Azure y la zonificación es Azure Policy.

Responsabilidades principales:

  • Definir y mantener las plantillas de golden path para cada arquetipo de servicio (API, worker, front-end, pipeline de datos)
  • Operar el catálogo estilo Backstage respaldado por Azure DevOps y GitHub Enterprise
  • Autorar y gobernar registros de decisiones arquitectónicas en un repo central de ADRs
  • Mantener la matriz de capacidades que mapea dominios de negocio a primitivas de plataforma
  • Establecer la iniciativa de policy en Azure Policy que aplica a cada suscripción dentro del alcance
  • Patrocinar el catálogo de MCPs validados y el modelo de gobernanza de agentes
  • Operar el agente Path Keeper y los prompts /golden-path, /template-new, /adr-platform, /capability-matrix

Jobs to be done

  1. Como Platform Architect, quiero que un nuevo repo de servicio se cree desde una plantilla golden path en minutos, para que los equipos arranquen en el camino pavimentado.
  2. Como Platform Architect, quiero que cada servicio declare sus capacidades en una matriz legible por máquina, para que la evolución de la plataforma sea data-driven.
  3. Como Platform Architect, quiero que los ADRs se redacten desde conversaciones de diseño, para que el registro de decisión nunca se omita.
  4. Como Platform Architect, quiero plantillas versionadas y propagadas vía PRs automatizados, para que el camino pavimentado se mantenga pavimentado.
  5. Como Platform Architect, quiero que la telemetría de uso de la plataforma fluya hacia Application Insights, para que las capacidades no usadas se retiren, no se acumulen.
  6. Como Platform Architect, quiero que el catálogo de MCPs se aplique en commit time, para que los equipos no puedan instalar MCPs no autorizados.

Puntos de dolor antes de la era AI-native

  1. Las plantillas se pudren. El repo de scaffolding no se ha actualizado en 14 meses. Los nuevos servicios arrancan en el camino viejo.
  2. Los ADRs son opcionales. Las decisiones se toman en llamadas, se documentan después o nunca. El contexto se evapora en seis meses.
  3. La matriz de capacidades es una hoja de cálculo. Nadie la actualiza; nadie confía en ella.
  4. Sprawl de policy. Cada suscripción crece sus propias definiciones de Azure Policy. Los reportes de cumplimiento son contradictorios.
  5. MCP a libre demanda. Cada equipo instala el MCP de la semana. La superficie de ataque de cadena de suministro explota.

Flujo diario AI-native

El Platform Architect opera un ciclo fijo cada día. El ciclo usa primitivas de GitHub Copilot dentro de Visual Studio Code y Claude Code en la terminal, más un pequeño catálogo de MCPs validados para contexto externo.

Setup de la mañana

  1. Abrir el monorepo de plataforma en Visual Studio Code. GitHub Copilot Chat carga AGENTS.md y los .github/instructions/*.instructions.md con alcance para plantillas y ADRs.
  2. En Claude Code, ejecutar un reporte diario que consulta el GitHub MCP por uso de plantillas, PRs de drift de plantilla y la cola de revisión de ADRs.
  3. Revisar la matriz de capacidades por cualquier servicio que cayó fuera de cumplimiento durante la noche (impulsado por Azure Policy y GitHub Advanced Security).
  4. Hacer triage de los pedidos entrantes de plantilla en Azure Boards.

Ejecución al mediodía

Cada ciclo de mediodía es un único cambio de plataforma, típicamente 2 a 4 horas de trabajo enfocado.

  1. Golden path. Invocar /golden-path con un arquetipo (API, worker, front-end, datos). El agente Path Keeper compone la plantilla desde módulos Bicep, workflows reutilizables de GitHub y el catálogo de MCPs validados.
  2. Cambio de plantilla. Invocar /template-new para versionar la plantilla, abrir una flota de PRs de rollout entre repos consumidores y adjuntar una guía de migración.
  3. ADR. Invocar /adr-platform para redactar un ADR desde la transcripción de la reunión de diseño. El agente llena las restricciones EARS, las opciones consideradas y la justificación de la decisión.
  4. Matriz de capacidades. Invocar /capability-matrix para refrescar el mapa dominio-a-primitiva desde el índice del catálogo de servicios.
  5. Pull request. La descripción del PR se compone desde el ADR y el diff de la plantilla. GitHub Copilot Code Review escanea por drift de policy.

Gobernanza en la tarde

  1. Ejecutar un reporte semanal de drift de plantillas en Azure Monitor. Servicios con más de dos versiones menores de retraso se marcan.
  2. Publicar el snapshot de la matriz de capacidades en el sitio de Microsoft 365 SharePoint para la reunión de revisión de plataforma.
  3. Hacer hand-off de cambios de infraestructura al DevOps Engineer; hand-off de cambios de postura de seguridad al InfoSec Officer.

Primitivas recomendadas

Agentes

AgenteArchivoPropósito
path-keeper.github/agents/path-keeper.agent.mdAutorar golden paths, gobernar plantillas, redactar ADRs, mantener la matriz de capacidades

El agente Path Keeper usa claude-sonnet-4-6 por defecto. Tiene herramientas read, edit, search, grep, glob, bash y bindings MCP a GitHub MCP Server y Azure DevOps MCP Server para recorrer el catálogo.

Prompts

ComandoArchivoPropósito
/golden-path.github/prompts/golden-path.prompt.mdComponer una nueva plantilla golden path para un arquetipo de servicio
/template-new.github/prompts/template-new.prompt.mdVersionar una plantilla y abrir la flota de PRs de rollout
/adr-platform.github/prompts/adr-platform.prompt.mdRedactar un ADR desde una transcripción de reunión de diseño o especificación
/capability-matrix.github/prompts/capability-matrix.prompt.mdRefrescar la matriz de capacidades dominio-a-primitiva

Instructions

El applyTo con alcance reduce el costo de tokens en aproximadamente 68 por ciento comparado con instrucciones globales.

Alcance (applyTo)ArchivoPropósito
templates/**/*.github/instructions/templates.instructions.mdEsquema de parámetros de plantilla, estructura del README, ruta de upgrade
adr/**/*.md.github/instructions/adr.instructions.mdFormato ADR: contexto, opciones, decisión, consecuencias
catalog/**/*.yaml.github/instructions/catalog.instructions.mdEsquema del catálogo, ownership, ciclo de vida

Skills

Los skills se cargan de forma perezosa, así que el Platform Architect puede instalar muchos y pagar tokens solo por los que se disparan.

  • template-drift-scan: llama al GitHub MCP para listar repos consumidores que aún están en versiones viejas de plantilla
  • mcp-catalog-enforcer: rechaza PRs que añaden MCPs no presentes en el catálogo validado

Hooks

Los hooks cuestan cero tokens de LLM. Son la capa de gobernanza más fuerte.

  • pre-commit: validar el esquema de parámetros de plantilla y el front matter del ADR
  • pre-merge: verificar el bump de versión de plantilla y la guía de migración en cualquier cambio de plantilla
  • post-merge: abrir PRs de rollout en repos consumidores vía el GitHub MCP

MCPs validados

Cada MCP a continuación está registrado en el catálogo de MCPs. No referencie ningún MCP que no esté en el catálogo.

MCPEstadoUso en esta persona
GitHub MCP ServerOficialRecorrido del catálogo, PRs de rollout de plantilla, telemetría de uso
Azure DevOps MCP ServerOficial (Microsoft)Leer tickets de intake, actualizar Azure Boards, gestionar plantillas de pipeline
Azure MCP ServerOficial (Microsoft)Consultar iniciativas de Azure Policy e inventarios de resource group
Microsoft Learn Docs MCPOficialConsultar el Azure Well-Architected Framework y guía de referencia de Azure durante la redacción de ADRs
Microsoft 365 Agents SDK MCPOficial (Microsoft)Publicar snapshots de matriz de capacidades y notificaciones de ADR en Teams y SharePoint
Playwright MCPOficial (Microsoft)Validar que las plantillas golden path arrancan smoke tests end-to-end funcionales

Ejemplos reales

Escenario A: lanzar un nuevo golden path de API

Entrada: La organización decide que cada nueva API interna debe usar Azure API Management, autenticación con Entra ID y un App Service desplegado por Bicep. Ningún otro arquetipo está permitido para APIs internas.

Invocación: /golden-path con arquetipo internal-api.

Salida esperada:

  1. Un repo de plantilla template-internal-api con módulo Bicep, workflow reutilizable de GitHub Actions, esqueleto de registro de app de Entra ID y scaffold de OpenAPI.
  2. Una iniciativa de Azure Policy que niega cualquier App Service creado fuera de esta plantilla.
  3. Un ADR adr/0042-internal-api-golden-path.md registrando la decisión, opciones consideradas y consecuencias.
  4. Una actualización de la matriz de capacidades enlazando el arquetipo internal-api con la instancia compartida de APIM.

Escenario B: propagar un cambio de plantilla con ruptura

Entrada: La organización actualiza el runtime estándar de .NET de 8 a 9. Cada servicio que use el golden path de API debe actualizarse.

Invocación: /template-new con el bump de versión de plantilla.

Salida esperada:

  1. Una nueva versión de plantilla template-internal-api@2.0.0 con el runtime actualizado y una guía de migración.
  2. Una flota de PRs abiertos por el agente Path Keeper en cada repo consumidor, cada uno con el diff de migración y un enlace al ADR.
  3. Un dashboard de drift en Application Insights que muestra adopción a lo largo del tiempo, publicado en la reunión de revisión de plataforma.

Anti-patrones

  1. Plantilla como página de wiki. Una página markdown que describe el golden path sin un motor de scaffolding. Mitigación: cada golden path es un repo de plantilla real con parámetros y tests.
  2. ADRs escritos a posteriori. Las decisiones se documentan meses después, si acaso. Mitigación: /adr-platform redacta desde la transcripción de la reunión de diseño durante la reunión.
  3. Matriz de capacidades manual. Una hoja de cálculo que nadie actualiza. Mitigación: /capability-matrix regenera desde el YAML del catálogo.
  4. MCP a libre demanda. Los equipos instalan cualquier MCP que encuentren. Mitigación: el skill mcp-catalog-enforcer rechaza PRs que referencian MCPs no catalogados.
  5. Policy por suscripción. Cada suscripción crece su propio árbol de Azure Policy. Mitigación: una sola iniciativa propiedad del Platform Architect, asignada en el management group.

KPIs y métricas de impacto

La persona Platform Architect se evalúa con una mezcla de métricas de platform engineering y experiencia de developer.

MétricaLínea base (manual)Meta (agéntico)Medición
Tiempo al primer commit en un nuevo servicio2 semanas< 1 díaTiempo desde intake al primer PR mergeado
Tasa de adopción de plantilla40 por ciento> 90 por cientoPorcentaje de servicios en el último golden path
Cobertura de ADR20 por ciento> 95 por cientoPorcentaje de decisiones arquitectónicas con un ADR vinculado
Frescura de la matriz de capacidadesTrimestralSemanalDías desde el último refresh
NPS de plataforma de los developersDesconocido> 40Encuesta trimestral
Cumplimiento de policy70 por ciento> 98 por cientoScore de cumplimiento de Azure Policy
Drift del catálogo de MCPsSin medir0 MCPs no catalogadosScan del repo
Eficiencia de tokensN/A< 300k tokens por versión de plantillaReporte de uso de Copilot

Madurez en cuatro niveles

NivelNombreMarcadores
L1ManualEl scaffolding es una página de wiki, ADRs opcionales, policies por suscripción
L2AsistidoExiste el repo de plantilla pero hace drift, GitHub Copilot ayuda a redactar ADRs ocasionalmente
L3AumentadoUn agente Path Keeper, cuatro slash prompts, instrucciones con alcance, dos MCPs, rollout de plantilla automatizado
L4AutónomoKit completo de primitivas, hooks aplicados, catálogo de MCPs aplicado, matriz de capacidades refrescada semanalmente, cobertura de ADR > 95 por ciento

Integración con otras personas

Hand-offs:

  • Desde el Enterprise Architect: arquitectura objetivo, patrones de referencia, temas de inversión
  • Desde el Software Architect: ADRs a nivel de servicio que escalan a decisiones de plataforma
  • Hacia el DevOps Engineer: workflows reutilizables, módulos Bicep, iniciativas de policy
  • Hacia el Developer: repo scaffolded, instrucciones con alcance, catálogo de MCPs validados
  • Hacia el InfoSec Officer: iniciativa de policy, catálogo de MCPs, esqueleto de registro de app de Entra ID

Glosario

  • Agente: un rol LLM configurado con herramientas, instrucciones y una forma de salida definida.
  • Prompt: un slash command reutilizable que invoca a un agente con una tarea específica.
  • Instructions: guía con alcance aplicada por coincidencia de patrón en rutas de archivos vía applyTo.
  • Skill: una capacidad cargada de forma perezosa que se activa por coincidencia de palabra clave.
  • Hook: una regla de cero tokens aplicada en un evento específico del ciclo de vida.
  • MCP: servidor Model Context Protocol que expone sistemas externos al agente.
  • Golden path: el camino pavimentado que cada equipo se espera use; cualquier desviación requiere un ADR.
  • IDP: Internal Developer Platform; el sistema que hace fácil seguir el golden path.
  • ADR: Architectural Decision Record; un archivo markdown fechado que captura contexto, opciones, decisión, consecuencias.
  • Matriz de capacidades: un mapa legible por máquina desde dominio de negocio a primitiva de plataforma.

Referencias