Definir o espaço de problema

À medida que você caminha para definir sua plataforma de desenvolvedor interna, é fundamental definir a TVP (plataforma viável) mais fina primeiro. Essa é uma variação da ideia de um MVP (produto mínimo viável) no gerenciamento de produtos clássicos.

Em Planejar e priorizar, você pode saber mais sobre como definir (ou aprimorar) seu TVP. Mas antes de chegarmos lá, esse diagrama pode ajudá-lo a orientar seu pensamento sobre como você pode evoluir ao longo do tempo. Tenha em mente que o principal problema da sua organização pode fazer com que você se desvie do que é descrito aqui devido aos seus investimentos ou necessidades organizacionais existentes. Criticamente, você não precisa passar para o próximo estágio, a menos que sua organização precise dela.

Se você estiver começando do zero, isso representa uma progressão comum. Nos estágios iniciais, concentre-se na descoberta dos recursos necessários, na análise de ajuste de lacuna de produtos encapsulados e na criação de ferramentas de número mínimo ou funcionalidades de plataforma. Em seguida, conforme você dimensiona, provavelmente começará a se concentrar na reutilização e na orientação das pessoas para caminhos pavimentados predefinidos com ativos reutilizáveis. Por fim, você se move em direção a um modelo de "repositório digital" semelhante ao consumidor para facilitar a criação e a manutenção de aplicativos. Você deve seguir uma mentalidade de produto durante todo o processo, portanto, não recomendamos pular para o final e sua jornada específica varia. Esses estágios finais mais se assemelham ao "produto" encolhido no sentido tradicional, mas este é um destino, não um ponto de partida.

Considerando o tamanho deste tópico, recomendamos dividir a forma como você fala sobre engenharia de plataforma em quatro áreas de tópico. Categorizar seu pensamento dessa maneira pode simplificar a forma como você estabelece e comunica um plano para seus investimentos ao longo do tempo. Essas áreas são:

• Sistemas de engenharia: uma combinação coletada de pacotes de DevOps, como o GitHub e o Azure DevOps e outras ferramentas e serviços para desenvolvedores. Além das ferramentas e serviços críticos do DevOps, como CI/CD ou gerenciamento de pacotes, essa área também inclui recursos usados diretamente durante o processo de codificação, como ambientes de codificação baseados em nuvem, scanners de código e litros e assistentes de IA, como GitHub Copilot.
• Plataforma de aplicativo: uma seleção coletada de serviços (como IaaS, PaaS e observabilidade) direcionados a cada "pilha de aplicativos" (classe de aplicativo, modelo de aplicativo, idiomas) que uma organização deseja usar para fornecer valor comercial. Isso inclui uma combinação de serviços específicos da pilha de aplicativos, juntamente com os serviços comuns usados em toda parte. Um exemplo de uma plataforma de aplicativo pode incluir Aplicativos de Contêiner do Azure, Cosmos DB para armazenamento, Key Vault do Azure para segredos, para controle de acesso baseado em identidade e função, Azure Policy para conformidade e auditoria, observabilidade por meio do Grafana e uma topologia de rede relacionada.
• Modelos de aplicativo: um conjunto de modelos de início rápido bem definidos, criados pela organização, que encapsulam o início correto e permanecem orientações corretas para uma determinada plataforma de aplicativo, linguagem e conjunto de sistemas de engenharia. Eles podem referenciar outros modelos centralizados e fornecer código inicial, referências de API e SDK, pipelines de CI/CD, configuração de ferramentas e muito mais.
• Recursos de autoatendimento do desenvolvedor: essa é a cola para seu esforço de engenharia de plataforma. É uma combinação de APIs, orquestradores, um catálogo, modelos e experiências de usuário projetadas para reduzir a labuta do desenvolvedor e permitir que as equipes de desenvolvimento se autoatendissem e sejam mais autônomas, aderindo a seleções e diretrizes/governança das três áreas anteriores.

Planejar e priorizar