O gargalo do fluxo rápido nas decisões de contratação e compra

O fluxo rápido pode morrer antes de chegar à arquitetura: morre quando a decisão de contratação ou compra é tomada por critérios que ignoram a natureza do domínio. Na apresentação de Michael Plöd em Adaptive Organizations meet Architecture, esse ponto aparece como uma tensão concreta entre arquitetos, que querem conhecimento interno e autonomia em áreas críticas, e áreas de procurement, que tendem a otimizar custo, reduzir fornecedores e evitar dependência contratual. O problema não é a existência de compras centralizadas. É tratar todos os sistemas como se tivessem o mesmo valor estratégico.

Plöd descreve um mecanismo simples. O arquiteto quer times estáveis, propriedade clara de domínio e capacidade interna onde o negócio se diferencia. O comprador pode ser premiado por conseguir 5% de desconto, independentemente do sucesso do projeto. Quando uma iniciativa precisa de velocidade, mas cai numa renegociação contratual, numa disputa por fornecedor mais barato ou numa dependência de escopo não previsto, o fluxo para. A consequência é conhecida: perda de conhecimento, dependência de fornecedor, atrito de comunicação, riscos de segurança e desmotivação.

A saída proposta não é uma regra contra terceirização. Plöd usa três lentes para tornar a decisão menos arbitrária: Domain-Driven Design, Cynefin e Wardley Maps. Domínios centrais, complexos ou em estágio inicial exigem proximidade, aprendizado e propriedade interna. Domínios genéricos, claros ou comoditizados tendem a pedir software pronto, SaaS ou terceirização mais estruturada. O exemplo de SAP ajuda a delimitar o risco: customizar pode fazer sentido em áreas de suporte, mas levar a lógica do pacote para uma diferenciação central ou customizar demais até impedir upgrades transforma uma compra eficiente em dívida operacional.

A mesma disciplina aparece na discussão sobre inteligência artificial. Plöd não trata IA como uma nova categoria de sourcing, mas como níveis de envolvimento: agentes de código, agentes orientados por especificação, modelagem assistida e ciclos de vida mais agentic. A pergunta prática continua sendo a mesma: qual é o domínio, quanta incerteza ele contém e quanto da capacidade precisa permanecer dentro da organização. Para empresas grandes, essa matriz pode ser mais útil do que uma preferência abstrata por construir, comprar ou terceirizar.

Assistir ao episódio original

Referências encontradas

Livros

• The Software Architect Elevator: Redefining The Architect's Role In The Digital Enterprise, de Gregor Hohpe — Ver livro na Amazon
• Accelerate: The Science Of Lean Software And DevOps: Building And Scaling High Performing Technology Organizations, de Nicole Forsgren, Jez Humble, Gene Kim — Ver livro na Amazon
• The Culture Map: Breaking Through The Invisible Boundaries Of Global Business, de Erin Meyer — Ver livro na Amazon

Este post contém links de afiliado. Se você comprar por eles, eu posso receber uma pequena comissão sem custo adicional para você.