Existe um conflito constante entre seguir técnicas ágeis e conseguir fazer arquitetura corporativa. Enquanto o desenvolvimento ágil concentra-se em ajustar a modelagem e o planejamento à medida que se ganha conhecimento sobre o domínio, a arquitetura estabelece uma plataforma tecnológica e trata dos atributos de qualidade, atendendo às partes interessadas. Uma combinação desses dois aspectos será bem-sucedida quando as técnicas ágeis forem usadas para atingir a arquitetura desejada.
Tom Graves sugere que a agilidade precisa um suporte fornecido pela arquitetura:
A agilidade necessita frequentemente de uma espinha dorsal para manter sua direção – algo que dê sustentação, evitando perda de direção e foco. Trata-se de conseguir o equilíbrio adequado entre o "osso" da arquitetura e o "músculo" da agilidade.
Jan Van Til concorda com Graves ao sugerir que, sem uma espinha dorsal subjacente, seria difícil enxergar o Agile acontecendo em primeiro plano:
Precisamos de um segundo plano que se movimente mais lentamente, para que seja possível distinguir a agilidade no primeiro plano. Se tudo for moda, ningém seria capaz de distinguir uma moda de outra. Em outras palavras: precisamos de tradição. Sem tradição não existe moda.
Simon Brown sugere que mesmo o "mais ágil dos projetos" traz certo nível de preocupações arquiteturais. Estas preocupações precisam ser tratadas durante as primeiras iterações. De acordo com Brown, o conflito entre Agile e Arquitetura acontece devido à entrega de valor em pequenos blocos, em vez da realização de um grande investimento inicial no projeto arquitetural. O segredo é projetar apenas o suficiente. É importante estabelecer uma estrutura de alto nível, mas isso não significa criar uma infinidade de diagramas de classes detalhados.
Por outro lado, John Bauer menciona um padrão que observou em vários projetos.
Abordagens ágeis têm um efeito colateral muito positivo: reduzir a ocorrência de soluções de software com excesso de arquitetura, que sobrecarregam a entrega do software e aumentam os custos de desenvolvimento e manutenção, geralmente de maneira desproporcional ao valor de negócio produzido.
James Coplien e Kevlin Henney apresentam uma forma eficaz de começar apenas com a arquitetura suficiente e assegurar o sucesso do projeto.
Mas como tudo isso funciona no mundo real?
Simon Brown postou um desafio interessante sobre como substituir um sistema de Internet banking que está ficando obsoleto em cerca de quatro meses. A ideia seria trabalhar de forma ágil e mesmo assim entregar o produto. Há algumas soluções propostas no próprio post, bem como outras sugeridas por Kero e John Bauer. É possível acompanhar as soluções e propor soluções adicionais.
Portanto, Agile e Arquitetura precisam coexistir; não são excludentes. É importante fazer "apenas o suficiente", o que Simon Brown explica da seguinte forma:
Defina apenas a arquitetura suficiente para obter clareza e visão, ou seja, para identificar o seu objetivo e como vai atingi-lo. A arquitetura representa as decisões importantes. A importância é medida pelo custo em se fazer mudanças: aspectos com custo alto de modificação devem ser definidos corretamente o mais cedo possível. Por exemplo, qualidades como alta escalabilidade, segurança e alta disponibilidade geralmente precisam estar embutidas desde o início, nos alicerces do sistema, porque são difíceis de incorporar a uma base de código preexistente. Outros exemplos de aspectos que devem ser tratados com atencedência são os que não podem ser refatorados facilmente em uma tarde, como escolhas de tecnologia e de padrões de arquitetura, frameworks básicos a serem utilizados, e assim por diante.