A Arquitetura de Software começa com um conjunto de escolhas de projeto feitas pela equipe na primeira versão do sistema. Geralmente estas escolhas são documentadas em “papel de pão” e ao final do sistema podem não representar a realidade.

Portanto, a única maneira de explicar a arquitetura consiste em realizar análises retrospectivas e atualizar os artefatos.

Imaturidade

A versão inicial do sistema é como uma criança: completa porém imatura e um pouco imprevisível. Ao passar do tempo, após diversos ciclos de evolução, ela torna-se sólida e madura.

Em outras palavras, os usuários e desenvolvedores ganham confiança no modelo aplicado e consciência das capacidades e limitações.

Contudo, o sucesso desta evolução deve ser apoiado em feedback constante e ajustes contínuos objetivando o sucesso. De forma similar, a arquitetura pode continuar imatura e estagnada sem este feedback.

Arquitetura de Software “Modinha”

Um dos critérios indicadores que uma arquitetura irá falhar está no “resumé oriented design” ou projeto orientado a “modinha”. Por exemplo, há decisões que são tomadas com base na vanguarda tecnológica sem uma correta avaliação do valor agregado ao projeto.

Portanto, corre-se o risco neste cenário de criar uma solução inútil que demandará recriar a arquitetura do zero. Em última instância, isto poderá afetar a vida do projeto ou do negócio devido a perda do time-to-market (leia mais aqui).

Forças de Influência

Há 3 forças de influência no modelo da arquitetura que impedem (ou direcionam) a escolha de uma padrão: tempo, natureza do problema e sensação de sucesso.

O tempo é a primeira força pois orienta decisões comerciais e aproveitamento de oportunidades. Portanto, não haverá tempo para experimentações ou aventuras. Em outras palavras, as soluções tendem a replicar sucessos do passado como forma de mitigar riscos.

A natureza do problema e o contexto nela inserido é a segunda força mais importante e de alto impacto visto que contém diretrizes importantes que guiam a escolha da Arquitetura.

Por exemplo, um web site para atender alto volume de clientes tende a utilizar um modelo consagrado. Da mesma maneira, um sistema de backoffice tende orientar a um modelo alinhado ao conceito de produtividade da área usuário.

Concluindo, é uma força que deixa pouco espaço para experimentações disruptivas pois tendem a trazer pouco valor. Porém, algumas porções da solução podem explorar modelos alternativos.

A terceira força consiste na percepção de sucesso da arquitetura e somente pode ser obtida após colocar ela em prática. Portanto, descobrir se a escolha foi correta é questão de tempo e feedback.

Conclusão

Geralmente o senso crítico ao desenvolver uma Arquitetura de Software deve se sobrepor as recomendações “by the book”. Em outras palavras, algumas das recomendações assumem como premissa a facilidade de experimentação e ausência total de conhecimento da solução do problema.

Contudo, na prática há um senso de direção de onde seguir e conhecimento prévio do que não funciona, excluindo assim esforços desnecessários que agregam pouco valor. A regra de Paretto aqui é válida: 30% das decisões tem que trazer 70% dos resultados.

No próximo artigo será apresentado uma breve explicação do que são padrões de projeto em Arquitetura de Software e sua importância (para uma visão mais detalhada de padrões de projeto existentes, clique aqui). Até mais!!!