A explos?o de interesse em torno das plataformas de software gerou muito valor para as organiza??es, mas o caminho para a constru??o de um modelo de entrega baseado em plataforma est¨¢ repleto de potenciais becos sem sa¨ªda. ? comum em meio ao entusiasmo com novos paradigmas ver t¨¦cnicas mais antigas ressurgindo repaginadas para incorporar o novo vern¨¢culo, contribuindo para perdermos de vista as raz?es pelas quais superamos essas t¨¦cnicas em primeiro lugar. Para ver um exemplo dessa repagina??o, veja nosso blip sobre os tradicionais ESBs disfar?ados de gateways de API na edi??o anterior do Radar. Outro exemplo que estamos vendo ¨¦ a reformula??o da abordagem de divis?o de times por camada de tecnologia, mas chamando-os de times de plataformas. No contexto de constru??o de uma aplica??o, costumava ser comum ter um time de front-end separado do time de l¨®gica de neg¨®cio, por sua vez separado do time de dados. Vemos analogias a esse modelo quando as organiza??es segregam os recursos da plataforma entre times dedicados a um neg¨®cio ou camada de dados. Gra?as ¨¤ Lei de Conway, sabemos que a organiza??o de times de recursos de plataforma em torno de ¨¦ um modelo mais eficaz, dando aos times a propriedade de ponta a ponta do recurso, incluindo a propriedade dos dados. Isso ajuda a evitar as dores de cabe?a com gerenciamento de depend¨ºncias de times de plataforma em camadas , com o time de front-end aguardando o time de l¨®gica de neg¨®cio aguardando o time de dados para conseguir concluir qualquer coisa.
