Seguimos viendo a los equipos de producto de ingenier¨ªa de plataformas como una opci¨®n sensata, con la idea principal de que no son m¨¢s que otro , aunque centrado en los clientes internos de la plataforma. Por lo tanto, es fundamental tener clientes y productos claramente definidos y utilizar las mismas disciplinas de ingenier¨ªa y formas de trabajo que cualquier otro equipo de producto (centrado en el exterior); los equipos de plataforma no son especiales en este sentido. Advertimos que no hay que limitarse a cambiar el nombre de los equipos internos existentes por el de "equipos de plataforma" sin cambiar los m¨¦todos de trabajo ni las estructuras organizativas. Seguimos siendo grandes seguidores del uso de los conceptos de cuando pensamos en la mejor manera de organizar los equipos de plataforma. Consideramos que los equipos de productos de ingenier¨ªa de plataformas son un enfoque est¨¢ndar y un importante facilitador de la TI de alto rendimiento.
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 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 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.
