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 capacidades comerciales 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.
