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

Arquiteto de Plataforma

Golden paths e IDP.

Atualizado: 2026-04-24 14 seções Baixar .zip

O Platform Architect é a persona que desenha as estradas pavimentadas por onde todos os times passam. Em um SDLC AI-native, o Platform Architect opera uma pilha de primitivas validadas, não um wiki cheio de diagramas aspiracionais.

Resumo executivo

O Platform Architect é dono do Internal Developer Platform: os templates de golden path, a matriz de capacidades e os registros de decisão arquitetural que moldam como todo time constrói. Em um SDLC AI-native, o Platform Architect opera dentro da fase de Platform com um conjunto fixo de primitivas: um agente de plataforma, quatro slash prompts, instruções escopadas, hooks validados por schema e uma lista curada de MCPs validados. A plataforma é entregue como um catálogo estilo Backstage com backing de Azure DevOps e GitHub Enterprise, com templates de serviço baseados em Bicep, reusable workflows do GitHub e initiatives do Azure Policy. As saídas primárias são repositórios de template, matrizes de capacidade, ADRs e uma experiência de desenvolvedor mensurável.

Papel e responsabilidades

Pense no Platform Architect como um urbanista. O urbanista não constrói os prédios; o urbanista define as ruas, utilidades, zoneamento e códigos de construção que permitem a milhares de construtores trabalharem em paralelo sem a cidade desabar. O sucesso do urbanista não é medido pelo número de prédios que desenhou, mas pelo tempo que leva para um novo construtor colocar o primeiro tijolo com confiança. Em um SDLC AI-native, a cidade é o Internal Developer Platform, as ruas são reusable workflows do GitHub Actions, as utilidades são serviços compartilhados do Azure e o zoneamento é Azure Policy.

Responsabilidades primárias:

  • Definir e manter os templates de golden path para cada arquétipo de serviço (API, worker, front-end, data pipeline)
  • Operar o catálogo estilo Backstage com backing de Azure DevOps e GitHub Enterprise
  • Escrever e governar registros de decisão arquitetural em um repo central de ADRs
  • Manter a matriz de capacidades que mapeia domínios de negócio para primitivas de plataforma
  • Definir a initiative de policy no Azure Policy que se aplica a toda assinatura no escopo
  • Patrocinar o catálogo de MCPs validados e o modelo de governança de agentes
  • Operar o agente Path Keeper e os prompts /golden-path, /template-new, /adr-platform, /capability-matrix

Jobs to be done

  1. Como Platform Architect, eu quero um novo repo de serviço criado a partir de um template de golden path em minutos, para que os times comecem na estrada pavimentada.
  2. Como Platform Architect, eu quero que todo serviço declare suas capacidades em uma matriz legível por máquina, para que a evolução da plataforma seja guiada por dados.
  3. Como Platform Architect, eu quero que ADRs sejam rascunhados a partir de conversas de design, para que o registro de decisão nunca seja pulado.
  4. Como Platform Architect, eu quero templates versionados e atualizados via PRs automatizados, para que a estrada pavimentada continue pavimentada.
  5. Como Platform Architect, eu quero que telemetria de uso da plataforma flua para o Application Insights, para que capacidades não usadas sejam aposentadas, não acumuladas.
  6. Como Platform Architect, eu quero que o catálogo de MCPs seja aplicado no commit, para que times não instalem MCPs piratas.

Dores antes da era AI-native

  1. Templates apodrecem. O repo de scaffolding não é atualizado há 14 meses. Novos serviços começam na estrada velha.
  2. ADRs são opcionais. Decisões são tomadas em calls, documentadas depois, ou nunca. O contexto evapora em seis meses.
  3. Matriz de capacidades é uma planilha. Ninguém atualiza; ninguém confia.
  4. Sprawl de policy. Cada assinatura cria suas próprias definições de Azure Policy. Relatórios de compliance ficam contraditórios.
  5. MCP liberação geral. Cada time instala o MCP da semana. A superfície de ataque de supply-chain explode.

Fluxo diário AI-native

O Platform Architect opera um loop fixo todo dia. O loop usa primitivas do GitHub Copilot dentro do Visual Studio Code e Claude Code no terminal, além de um pequeno catálogo de MCPs validados para contexto externo.

Setup da manhã

  1. Abra o monorepo de plataforma no Visual Studio Code. GitHub Copilot Chat carrega o AGENTS.md e os .github/instructions/*.instructions.md escopados para templates e ADRs.
  2. No Claude Code, rode um relatório diário que consulta o GitHub MCP para uso de templates, PRs de drift de template e fila de review de ADRs.
  3. Revise a matriz de capacidades para qualquer serviço que caiu em não-compliance durante a madrugada (guiado por Azure Policy e GitHub Advanced Security).
  4. Faça triage de pedidos de template entrantes no Azure Boards.

Execução no meio do dia

Cada ciclo de meio de dia é uma única mudança de plataforma, tipicamente 2 a 4 horas de trabalho focado.

  1. Golden path. Invoque /golden-path com um arquétipo (API, worker, front-end, data). O agente Path Keeper compõe o template a partir de módulos Bicep, reusable workflows do GitHub e do catálogo de MCPs validados.
  2. Mudança de template. Invoque /template-new para versionar o template, abrir uma frota de PRs de rollout nos repos consumidores e anexar um guia de migração.
  3. ADR. Invoque /adr-platform para rascunhar um ADR a partir do transcript da reunião de design. O agente preenche as restrições EARS, as opções consideradas e o racional da decisão.
  4. Matriz de capacidades. Invoque /capability-matrix para atualizar o mapa domínio-para-primitiva a partir do índice do catálogo de serviços.
  5. Pull request. A descrição do PR é composta a partir do ADR e do diff do template. GitHub Copilot Code Review escaneia em busca de drift de policy.

Governança no fim da tarde

  1. Rode um relatório semanal de drift de template no Azure Monitor. Serviços mais de duas versões menores atrás são sinalizados.
  2. Publique o snapshot da matriz de capacidades no site Microsoft 365 SharePoint para a reunião de review de plataforma.
  3. Entregue mudanças de infraestrutura ao DevOps Engineer; entregue mudanças de postura de segurança ao InfoSec Officer.

Primitivas recomendadas

Agentes

AgenteArquivoPropósito
path-keeper.github/agents/path-keeper.agent.mdEscrever golden paths, governar templates, rascunhar ADRs, manter a matriz de capacidades

O agente Path Keeper usa claude-sonnet-4-6 por padrão. Ele carrega ferramentas read, edit, search, grep, glob, bash e ligações MCP ao GitHub MCP Server e Azure DevOps MCP Server para traversal do catálogo.

Prompts

ComandoArquivoPropósito
/golden-path.github/prompts/golden-path.prompt.mdCompor um novo template de golden path para um arquétipo de serviço
/template-new.github/prompts/template-new.prompt.mdVersionar um template e abrir a frota de PRs de rollout
/adr-platform.github/prompts/adr-platform.prompt.mdRascunhar um ADR a partir de um transcript de reunião de design ou especificação
/capability-matrix.github/prompts/capability-matrix.prompt.mdAtualizar a matriz de capacidades domínio-para-primitiva

Instruções

Um applyTo escopado reduz o custo em tokens em aproximadamente 68 por cento em comparação com instruções globais.

Escopo (applyTo)ArquivoPropósito
templates/**/*.github/instructions/templates.instructions.mdSchema de parâmetros de template, estrutura de README, caminho de upgrade
adr/**/*.md.github/instructions/adr.instructions.mdFormato de ADR: contexto, opções, decisão, consequências
catalog/**/*.yaml.github/instructions/catalog.instructions.mdSchema de catálogo, ownership, ciclo de vida

Skills

Skills são lazy-loaded, então o Platform Architect pode instalar muitas e pagar tokens só pelas que forem ativadas.

  • template-drift-scan: chama o GitHub MCP para listar repos consumidores ainda em versões velhas de template
  • mcp-catalog-enforcer: recusa PRs que adicionam MCPs que não estão no catálogo validado

Hooks

Hooks custam zero tokens de LLM. São a camada mais forte de governança.

  • pre-commit: validar schema de parâmetros de template e front matter do ADR
  • pre-merge: verificar bump de versão de template e guia de migração em qualquer mudança de template
  • post-merge: abrir PRs de rollout nos repos consumidores via GitHub MCP

MCPs validados

Todos os MCPs abaixo estão registrados no catálogo de MCPs. Não referencie nenhum MCP que não esteja no catálogo.

MCPStatusUso nesta persona
GitHub MCP ServerOficialTraversal de catálogo, PRs de rollout de template, telemetria de uso
Azure DevOps MCP ServerOficial (Microsoft)Ler tickets de intake, atualizar Azure Boards, gerenciar templates de pipeline
Azure MCP ServerOficial (Microsoft)Consultar initiatives do Azure Policy e inventários de resource group
Microsoft Learn Docs MCPOficialBuscar guia do Azure Well-Architected Framework e referências Azure durante a autoria de ADR
Microsoft 365 Agents SDK MCPOficial (Microsoft)Publicar snapshots da matriz de capacidades e notificações de ADR no Teams e SharePoint
Playwright MCPOficial (Microsoft)Validar que templates de golden path fazem bootstrap de smoke tests ponta a ponta funcionais

Exemplos reais

Cenário A: lançar um novo golden path de API

Entrada: A organização decide que toda nova API interna deve usar Azure API Management, auth Entra ID e um App Service deployado via Bicep. Nenhum outro arquétipo é permitido para APIs internas.

Invocação: /golden-path com arquétipo internal-api.

Saída esperada:

  1. Um repo de template template-internal-api com módulo Bicep, reusable workflow do GitHub Actions, esqueleto de app registration no Entra ID e scaffold OpenAPI.
  2. Uma initiative do Azure Policy que nega qualquer App Service criado fora deste template.
  3. Um ADR adr/0042-internal-api-golden-path.md registrando a decisão, opções consideradas e consequências.
  4. Uma atualização da matriz de capacidades linkando o arquétipo internal-api à instância compartilhada de APIM.

Cenário B: fazer roll forward de uma mudança breaking de template

Entrada: A organização faz upgrade do runtime padrão de .NET de 8 para 9. Todo serviço usando o golden path de API precisa fazer upgrade.

Invocação: /template-new com o bump de versão do template.

Saída esperada:

  1. Uma nova versão de template template-internal-api@2.0.0 com o runtime bumpado e um guia de migração.
  2. Uma frota de PRs abertos pelo agente Path Keeper em cada repo consumidor, cada um com o diff de migração e um link para o ADR.
  3. Um dashboard de drift no Application Insights que mostra adoção ao longo do tempo, publicado na reunião de review de plataforma.

Anti-padrões

  1. Template como página de wiki. Uma página markdown que descreve o golden path sem um engine de scaffolding. Mitigação: todo golden path é um repo de template real com parâmetros e testes.
  2. ADRs escritos depois dos fatos. Decisões são documentadas meses depois, se é que são. Mitigação: /adr-platform rascunha a partir do transcript da reunião de design durante a reunião.
  3. Matriz de capacidades manual. Uma planilha que ninguém atualiza. Mitigação: /capability-matrix regenera a partir do YAML do catálogo.
  4. MCP liberação geral. Times instalam qualquer MCP que encontram. Mitigação: skill mcp-catalog-enforcer recusa PRs que referenciam MCPs não catalogados.
  5. Policy por assinatura. Cada assinatura cria sua própria árvore de Azure Policy. Mitigação: uma única initiative de propriedade do Platform Architect, atribuída no management group.

KPIs e métricas de impacto

A persona Platform Architect é avaliada com uma mistura de métricas de engenharia de plataforma e experiência de desenvolvedor.

MétricaLinha base (manual)Meta (agentic)Medição
Tempo até o primeiro commit em um novo serviço2 semanas< 1 diaTempo do intake até o primeiro PR merged
Taxa de adoção de template40 por cento> 90 por centoPorcentagem de serviços no último golden path
Cobertura de ADR20 por cento> 95 por centoPorcentagem de decisões arquiteturais com ADR linkado
Frescor da matriz de capacidadesTrimestralSemanalDias desde a última atualização
NPS de plataforma dos desenvolvedoresDesconhecido> 40Pesquisa trimestral
Compliance de policy70 por cento> 98 por centoScore de compliance do Azure Policy
Drift do catálogo de MCPsNão medido0 MCPs não catalogadosScan de repo
Eficiência de tokensN/A< 300k tokens por versão de templateRelatório de uso do Copilot

Maturidade em quatro níveis

NívelNomeMarcadores
L1ManualScaffolding é uma página de wiki, ADRs opcionais, policies por assinatura
L2AssistidoRepo de template existe mas deriva, GitHub Copilot ajuda a rascunhar ADRs ocasionalmente
L3AumentadoUm agente Path Keeper, quatro slash prompts, instruções escopadas, dois MCPs, rollout de template automatizado
L4AutônomoKit completo de primitivas, hooks aplicados, catálogo de MCPs aplicado, matriz de capacidades atualizada semanalmente, cobertura de ADR > 95 por cento

Integração com outras personas

Hand-offs:

  • Do Enterprise Architect: arquitetura-alvo, patterns de referência, temas de investimento
  • Do Software Architect: ADRs em nível de serviço que sobem para decisões de plataforma
  • Para DevOps Engineer: reusable workflows, módulos Bicep, initiatives de policy
  • Para Developer: repo com scaffold, instruções escopadas, catálogo de MCPs validados
  • Para InfoSec Officer: initiative de policy, catálogo de MCPs, esqueleto de app registration no Entra ID

Glossário

  • Agente: um papel de LLM configurado com ferramentas, instruções e uma forma de saída definida.
  • Prompt: um slash command reutilizável que invoca um agente com uma tarefa específica.
  • Instruções: guia escopado aplicado por pattern match em caminhos de arquivo via applyTo.
  • Skill: uma capacidade lazy-loaded que ativa em match de keyword.
  • Hook: uma regra de custo zero em tokens aplicada em um evento específico do ciclo de vida.
  • MCP: Model Context Protocol server que expõe sistemas externos ao agente.
  • Golden path: a estrada pavimentada que todo time deve usar; desvio requer um ADR.
  • IDP: Internal Developer Platform; o sistema que torna o golden path fácil de seguir.
  • ADR: Architectural Decision Record; um arquivo markdown datado que captura contexto, opções, decisão, consequências.
  • Matriz de capacidades: um mapa legível por máquina de domínio de negócio para primitiva de plataforma.

Referências