Para quem não sabe para onde vai, qualquer caminho serve

alice-wonderland-costume-tim-burton-549x700Há 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 a melhor que o B, mas caso exista outro requisitos relacionado com 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 esta relacionado em abrir um ponto de visão 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 a necessidades e cenários emergentes.

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

  • A solução estará disponível dentro da corporação (intranet)?
  • A solução estará disponível fora da corporação (internet)? Por quê?
  • Existe alguma previsão de ser disponibilizado publicamente fora da corporação (internet)? Por que e quando?
  • Qual é a previsão de usuários totais habilitados?
  • Existe previsão de aumento desse número de usuários habilitados? A partir do que isso pode acontecer?
  • Qual é a previsão da média de usuários simultâneos usando a solução?
  • Existe previsão de aumento dessa média de usuários simultâneos? A partir do que isso pode acontecer?
  • Quais tipos de plataformas e ou dispositivos móveis serão usados para acessar a solução? Por quê?
  • É desejável que a maior parte das funcionalidades da aplicação possa se acessadas via teclado (sem auxilio do mouse)?
  • A solução precisará ter integrações com sistemas externos, parceiros ou legados? Para que? Como será feito? Existem restrições?
  • Qual a disponibilidade a aplicação deve ter? 5×8? 7×8? 5×24, 7X24? Ela pode ficar fora do ar(downtime)? Quanto tempo? Existem problemas com isso? Quais?
  • E por ai vai…..
Caso você interesse em aprender a lhe com este tipo de situação é que nos oferecemos um treinamento de Arquiteto de Software Java que cobre estes e muitos outros aspectos relacionados.
“Do SENHOR é a salvação, e sobre o teu povo, a tua bênção.” 

Salmos 3:8

Anúncios