Continuamos vendo times de produto de engenharia de plataforma como um padrão sensato. O insight principal é que são times de produto como quaisquer outros, embora tenham foco em clientes da plataforma interna. Portanto, é fundamental ter clientes e produtos claramente definidos, usando as mesmas disciplinas da engenharia e formas de trabalhar de qualquer outra equipe de produto (com foco externo) — os times de plataforma não são especiais nesse aspecto. Desaconselhamos fortemente a prática de apenas renomear equipes internas existentes como “times de plataforma”, mas sem alterar as formas de trabalho e estruturas organizacionais. Ainda somos grandes fãs dos conceitos de topologias de time ao considerar a melhor forma de organizar equipes de plataforma. Consideramos os times de produto de engenharia de plataforma uma abordagem padrão e um elemento facilitador significativo para a TI de alto desempenho.
Conforme observado em um dos temas desta edição, a indústria vem ganhando cada vez mais experiência com times de produto de engenharia de plataforma , que criam e oferecem suporte a plataformas internas. Essas plataformas são usadas pelos times de uma organização e aceleram o desenvolvimento de aplicações, reduzem a complexidade operacional e melhoram o tempo de chegada ao mercado. Com o aumento da adoção, também ficam mais evidentes os padrões bons e ruins dessa abordagem. Ao criar uma plataforma, é fundamental definir clientes e produtos que serão beneficiados, em vez de construí-la no vácuo. Advertimos contra times de plataforma em camadas que simplesmente preservam silos de tecnologia existentes sob o rótulo de "times de plataforma", e também contra modelos operacionais de plataforma orientados a tickets. Ainda defendemos fortemente o uso de conceitos da abordagem de topologias de time quando pensamos sobre a melhor forma de organizar times de plataforma. Consideramos os times de produto de engenharia de plataforma uma abordagem padrão e um facilitador significativo para a TI de alta performance.
A adoção de nuvem e DevOps, embora aumente a produtividade dos times que agora podem se mover mais rapidamente com dependência reduzida de infraestrutura e times de operações centralizados, também restringiu os times que não possuem as habilidades necessárias para autogerenciar uma stack completa de aplicativos e operações. Algumas organizações enfrentaram esse desafio criando times de produto de engenharia de plataforma. Esses times mantêm uma plataforma interna que permite aos times de entrega implantar e operar sistemas com prazo de entrega reduzido e complexidade de stack. A ênfase aqui está nas ferramentas de autoatendimento e suporte orientadas à API, com os times de entrega ainda responsáveis por dar suporte ao que implementam na plataforma. As organizações que consideram estabelecer um time de plataforma devem ter muito cuidado para não criar acidentalmente um time separado de DevOps, nem devem simplesmente renomear sua estrutura existente de hospedagem e operações como uma plataforma. Se você está se perguntando qual é a melhor configuração para os times de plataforma, usamos os conceitos de topologias de time para dividir os times de plataforma em nossos projetos em times habilitadores, times de "plataforma em uma plataforma" e times alinhados com o fluxo.
The adoption of cloud and DevOps, while increasing the productivity of teams who can now move more quickly with reduced dependency on centralized operations teams and infrastructure, also has constrained teams who lack the skills to self-manage a full application and operations stack. Some organizations have tackled this challenge by creating platform engineering product teams. These teams operate an internal platform which enables delivery teams to self-service deploy and operate systems with reduced lead time and stack complexity. The emphasis here is on API-driven self-service and supporting tools, with delivery teams still responsible for supporting what they deploy onto the platform. Organizations that consider establishing such a platform team should be very cautious not to accidentally create a separate DevOps team, nor should they simply relabel their existing hosting and operations structure as a platform.
The adoption of cloud and DevOps, while increasing the productivity of teams who can now move more quickly with reduced dependency on centralized operations teams and infrastructure, also has constrained teams who lack the skills to self-manage a full application and operations stack. Some organizations have tackled this challenge by creating platform engineering product teams. These teams operate an internal platform which enables delivery teams to self-service deploy and operate systems with reduced lead time and stack complexity. The emphasis here is on API-driven self-service and supporting tools, with delivery teams still responsible for supporting what they deploy onto the platform. Organizations that consider establishing such a platform team should be very cautious not to accidentally create a separate DevOps team, nor should they simply relabel their existing hosting and operations structure as a platform.
