Como se mencionó en uno de los temas de esta edición, la industria está ganando cada vez más experiencia con los equipos de producto de ingeniería de plataforma que crean y dan soporte a plataformas internas. Estas son utilizadas por los equipos de toda la organización y aceleran el desarrollo de aplicaciones, reducen la complejidad operativa y mejoran el tiempo de comercialización. Con una adopción cada vez mayor, también tenemos más claros los patrones buenos y malos de este enfoque. Al crear una plataforma, es fundamental tener clientes y productos claramente definidos que se beneficiarán de ella en lugar de construir en el vacío. Advertimos en contra de los equipos de plataforma en capas, que conservan los silos de tecnología existentes pero se aplican la etiqueta de "equipo de plataforma", y también contra los modelos operativos de plataforma basados en tickets. Todavía somos partidarios de utilizar los conceptos de Team Topologies mientras pensamos en cómo organizar mejor a los equipos de plataforma. Consideramos que los equipos de producto de ingeniería de plataforma son un enfoque estándar y un habilitador significativo para lograr TI de alto rendimiento.

La adopción de la nube y de DevOps, al tiempo que aumentan la productividad de los equipos, que ahora pueden moverse más rápido y con menos dependencias hacia los equipos de operaciones centralizados y a la infraestructura, también ha limitado a los equipos que no tienen la habilidad de autogestionar una aplicación completa y el juego de operaciones. Algunas organizaciones han abordado este desafío creando equipos de producto de ingeniería de plataforma. Estos equipos mantienen una plataforma interna que les permite a los equipos de entrega implementar y operar sistemas en menos tiempo y con herramientas más sencillas. El énfasis está en el autoservicio basado en APIs y en las herramientas de soporte, manteniendo a los equipos de entrega responsables de soportar lo que desplieguen en la plataforma. Las organizaciones que consideran establecer un equipo de plataforma de este tipo deben tener cuidado de no crear accidentalmente un equipo de DevOps separado, ni tampoco simplemente renombrar su estructura existente de alojamiento y operaciones a plataforma. Si te preguntas cómo configurar mejor los equipos de plataforma, hemos estado utilizando los conceptos de Team Topologies para dividir los equipos de plataforma en nuestros proyectos en equipos habilitadores, equipos de "plataforma dentro de una plataforma" y equipos alineados con el flujo.

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.