La explosi¨®n de inter¨¦s en torno a las plataformas de software ha creado mucho valor para las organizaciones, pero el camino hacia la construcci¨®n de un modelo de entrega basado en plataformas est¨¢ plagado de posibles callejones sin salida. Por la emoci¨®n que traen los nuevos paradigmas, es com¨²n ver un resurgimiento de t¨¦cnicas antiguas marcadas con la nueva lengua vern¨¢cula, lo que hace que sea f¨¢cil perder de vista las razones por las que superamos esas t¨¦cnicas en primer lugar. Para ver un ejemplo de este cambio de marca, revisa nuestro blip sobre los ESBs disfrazados de API Gateways en la edici¨®n anterior del Radar. Otro ejemplo que estamos viendo es repetir el enfoque de dividir a los equipos por capa de tecnolog¨ªa, pero llam¨¢ndolos plataformas. En el contexto de la construcci¨®n de una aplicaci¨®n, era com¨²n tener un equipo de front-end separado del equipo que se encarga de la l¨®gica empresarial, separado del equipo de datos, y vemos an¨¢logos a ese modelo cuando las organizaciones segregan las capacidades de la plataforma entre los equipos dedicados a una capa de negocio o de datos. Gracias a la Ley de Conway, sabemos que organizar equipos de capacidades de plataforma en torno a es un modelo m¨¢s eficaz, que permite al equipo empoderarse de la capacidad completamente, incluyendo los datos. Esto ayuda a evitar los dolores de cabeza de la gesti¨®n de dependencias de equipos de plataforma en capas , con el equipo de front-end esperando al equipo de la l¨®gica de negocio, esperando al equipo de datos para hacer cualquier cosa.
