Seis Benefícios da Arquitetura de Software (bem-feita!)

Neste post, compartilho seis benefícios gerados por um bom projeto de Arquitetura de Software.  Cada um desses benefícios ajuda a gerar ótimos sistemas. Além disso, são facilmente compreendidos e bem avaliados pelos stakeholders.

Esta relação é inspirada em uma proposta de Michael Keeling, no excelente livro “Design It!”.

1. Problemas grandes fracionados em partes menores e gerenciáveis

Gosto de definir arquitetura de software como sendo a relação dos componentes de uma aplicação, a descrição de suas responsabilidades e da forma como se relacionam.

Sistemas modernos são grandes e complexos. Uma boa arquitetura de software, ajuda a explicar como um sistema poderia e ser particionado em componentes, reduzindo, assim, a complexidade para seu entendimento.

Componentes coesos e bem definidos podem operar de forma quase independente. Da mesma forma, podem ser desenvolvidos por times especialistas que podem, então, se aprofundar em especificidades do negócio.

2. Facilidade para formar times de trabalho

Desenvolvimento de Software é uma atividade humana. Uma boa arquitetura de software descreve como os diversos componentes de um sistema devem operar e como eles devem se comunicar. Com essa perspectiva, é mais fácil pensar em como estruturar times que os irão desenvolver.

Quando conhecemos a arquitetura, podemos pensar em como as pessoas podem colaborar para desenvolver o software. Quanto maior o sistema, mais importante torna-se a arquitetura. (Michael Keeling)

3. Vocabulário para o debate de temas complexos

Comunicação é um aspecto chave para o trabalho em equipe.

No lugar de gastar horas inventando um vocabulário e conceitos, podemos usar os conceitos e vocabulários essenciais descobertos na arquitetura como base para a colaboração. (Michael Keeling)

De tudo que aprendi sobre Domain-Driven Design, o que mais gosto e vejo frequentemente subestimado é o conceito de Linguagem Ubíqua. Trata-se de uma idéa fácil de entender, mas raramente bem implementada – talvez pela aparente facilidade.

O tempo gasto na explicitação da linguagem ubíqua é mais do que compensado na melhoria do entendimento do negócio e aperfeiçoamento da arquitetura. Aliás, quanto mais íntima for a implementação, menores as chances de corrosão da arquitetura.

4. Visão além de Features e Funcionalidades

Features e funcionalidades são muito importantes, sem dúvidas. Mas elas não são os únicos elementos que determinam se um software é bom ou não.

Quando pensamos em arquitetura, temos que considear elementos como custo, restrições, agendas, riscos e a habilidade do time para entregar o que está sendo pedido. Por exemplo, nem sempre a linguagem mais “natural” para expressar o domínio do problema é a escolha acertada para um projeto – temos que considerar o custo de preparar o time para usar a linguagem.

5. Erros Caros são mais facilmente evitados

Pense no seguinte:

Arquitetura de software são as coisas importantes de um software. O que quer que isso seja. (Martin Fowler)

Podemos interpretar coisas importantes como aquelas com alto custo para mudança.  A visão holística do sistema permite a quem está definindo a arquitetura (arquiteto?) identificar onde estão os aspectos críticos e potenciais dificuldades.

Em minha experiência, o Princípio de Pareto se aplica perfeitamente ao conjunto de elementos de um sistema. 20% deles são responsáveis por 80% da dificuldade (são os “pontos de dor” do sistema).  Arquitetura de software bem-feita deixa explícito quais são esses 20%.

6. Agilidade

Michael Keeling compara a forma como software responde a mudança a água – contornando obstáculos.

Se software é como água, que se ajusta a qualquer recepiente, então a arquitetura do software é o recepiente que dá forma ao software. (Michel Keeling).

Assim como a água, um software sem uma definição arquitetônica, segue o caminho que oferece menos resistência de forma incontrolável. A arquitetura de software fornece a estrutura para que a mudança seja possível.

Sem facilidade para suportar mudanças, não há agilidade.

Concluindo

Nesse post falei sobre seis benefícios oriundos de arquitetura de software bem-feita. Há outras ideias que poderiam ser exploradas. Mas, essas são mais do que suficientes para justificar o pensamento arquitetônico de forma planejada.