Continuamos vendo times de produto de engenharia de plataforma como um padr?o sensato. O insight principal ¨¦ que s?o 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 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 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 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.
