Há uma cena que quero comentar na obra “Alice no país das maravilhas”: o encontro de Alice com o gato. Na cena, Alice está perdida e de repente vê, no alto da árvore, o gato. Ela olha para ele lá em cima e diz assim:

Alice: “Você pode me ajudar?”
Gato: “Sim, pois não.”
Alice: “Para onde vai essa estrada?”
Gato: “Para onde você quer ir?”
Alice: “Eu não sei, estou perdida.”
Gato: “Para quem não sabe para onde vai, qualquer caminho serve.”

Muitas vezes vejo um pessoal de desenvolvimento me perguntando nos fóruns, e-mails e listas por ai algo do como:

“Qual melhor framework jA ou jB? Qual a melhor plataforma A , B, C? Qual melhor arquitetura em fazer C, D ou F? Qual framework web usar jWeb1, jWeb2 ou jWeb3?”

Como alguém poderia decidir por exemplo em usar JSF ou VRaptor ou ExtJ se não sabe os detalhes relacionados aos requisitos, contexto, ambiente e restrições da solução? A resposta seria igual ao do gato: “Para quem não sabe para onde vai, qualquer caminho serve”. Ou até pior, os céticos poderiam detonar uma opção e exaltar a outra ou pode aparecer aqueles com “bagagem emocional” dizendo “usa aquela opção que é legal, eu gosto muito”.

O responsável por essa decisão deve fazer as escolhas arquiteturais e tecnológicas baseadas em justificativas coerentes no próprio cenário de requisitos existente a ser alcançado, características, restrições e outros limitadores corporativos externos como: custo, investimento, capacitação, curva de aprendizado, produtividade, gestão de equipe, cronograma e etc.  As características da solução irão inevitavelmente se contradizer, alguma decisão deverá ser tomada, não será possível agradar todas elas e algum caminho precisará ser traçado. A coisa funciona mais ou menos assim:

Exemplo 1

• Contexto: Preciso viajar de Curitiba para São Paulo
• Soluções: moto? carro? caminhão? avião?
• Decisão: carro.
• Justificativa: moto demora, não tenho carteira para caminhão e não tenho dinheiro para passagem de avião.

Exemplo 2

• Contexto: Preciso viajar de Curitiba para São Paulo e levar uma geladeira
• Soluções: moto? carro? caminhão? avião?
• Decisão: caminhão.
• Justificativa: moto não resolve, carro não resolve, e não tenho dinheiro para passagem de avião.

Exemplo 3

• Contexto: Preciso viajar de Curitiba para São Paulo, levar uma geladeira e participar de uma reunião de negocio daqui 2 horas.
• Soluções: moto? carro? caminhão? avião?
• Decisão: sou obrigado a gastar com avião.
• Justificativa: moto não resolve, carro não resolve, caminhão não resolve.

Como pode ser percebido, se existir um requisito tal de produtividade, talvez o framework A pode ser melhor que o B; mas caso exista outro requisitos relacionados à segurança que pese mais que outras características, o framework B pode mais adequado que o A. Não existe melhor ou pior, tudo está depende de um ponto de vista baseado em conhecer as opções, suas vantagens, desvantagens, virtudes, fraquezas e contrastar com os pesos dos requisitos. Com este ponto de vista, dizemos que a arquitetura emerge destas informações.

Uma vez que o projeto começa a andar e pequenas fatias de releases começam a ser entregues, a solução pode passar mudanças de requisitos, características, ambientes e restrições, precisando então ser melhorada e evoluída para um próximo nível. Outra arquitetura emerge então destas novas informações respondendo rapidamente à necessidades e cenários emergentes.

Questionamentos básicos funcionais e não-funcionais de uma solução precisam ser esclarecidos como: