Embora seja colocada ênfase na criação da Arquitetura de Software, a maior parte do tempo é investida na sua evolução. Este processo de evolução, que envolve também a maturidade do sistema, é guiado pelo uso contínuo e o feedback constante dos clientes.

Apesar das empresas solicitarem feedback constante, o seu uso mais efetivo ocorre no planejamento da próxima versão. Em outras palavras, a próxima versão procura mapear as funcionalidades que serão implementadas com as necessidades levantadas junto aos clientes.

Portanto, a realização destas funcionalidades está intimamente ligada com a capacidade da Arquitetura de Software em atendê-las. Este equilíbrio entre as funcionalidades e as capacidades da arquitetura do sistema irá guiar sua evolução ao longo do tempo.

Funcionalidades

Funcionalidades definem coisas que um produto ou sistema fazem (ou deveriam fazer). Algumas frases que definem uma funcionalidade são:

• “O sistema deveria fazer….”
• “Nós queremos que o produto tenha…”
• “O sistema deve atender 1.000 usuários simultâneos….”

Uma funcionalidade pode ser composta por um ou mais requisitos, sejam eles técnicos ou de negócios. Além do mais, uma vez priorizada por negócios, as dependências técnicas relativas a esta funcionalidade devem estar claras pela equipe responsável pelo desenvolvimento, minimizando ao máximo ruídos de entendimento.

Dentre diversas maneiras de se documentar uma funcionalidade, utilizar o modelo de casos de uso tende a ser mais assertivo. Um caso de uso objetiva colocar contexto na funcionalidade a partir da perspectiva do ator, seja ele uma pessoa ou um sistema.

Por fim, a Arquitetura de Software determina o quão fácil é implementar uma determinada funcionalidade. Boas arquiteturas em geral são aquelas que são fáceis de incluir novas funcionalidades.

Capacidades

Capacidade é a habilidade da Arquitetura de Software em suportar um conjunto de funcionalidades. A importância deste atributo reside nos cenários onde negócios solicita uma demanda que muitas vezes é difícil de atender (ou mesmo impossível) devido a uma limitação técnica (ou arquitetural).

Em outras palavras, a capacidade da Arquitetura pode potencializar ou limitar a capacidade do produto ou do negócio.

Desenvolvimento Cíclico

A integração entre maturação e evolução do modelo pode ser definido como uma função entre o tempo e os ciclos de lançamentos. Acima de tudo, a equipe de desenvolvimento não implementa dos as funcionalidades em um único ciclo. Como o foco nos próximos lançamentos está em entregar funcionalidades, pouco tempo é reservado para rever (ou mudar) a arquitetura inicial.

Contudo, a medida que o produto evolui, as funcionalidades iniciais tendem a ser insuficientes para atender as demandas dos clientes. Neste sentido, as áreas de negócios buscam implementar funcionalidades com base no feedback dos clientes.

Em resumo, o ciclo de evolução do sistema e da arquitetura tem 2 momentos bem distintos:

1. As funcionalidades iniciais são priorizadas pela área de negócio com o objetivo de disponibilizar o produto ou sistema aos usuários;
2. Após alguns ciclos de evolução, geralmente as demandas dos usuários irão guiar a construção de funcionalidades que serão priorizadas (ou não) pela área de negócios;

Potencialidade X Agilidade

Potencialidade do modelo está diretamente associada as capacidades da Arquitetura ofertada. Em geral, se as requisições das áreas de negócios são atendidas sem grandes impactos na Arquitetura vigente, o modelo é tido como adequado ao negócio.

Além disso, a agilidade está associada a facilidade e a velocidade na qual as demandas são atendidas. Conflitos entre as equipes técnicas e de negócios são minimizados devido a clareza do caminho técnico que pode ser aplicado.

Portanto, o modelo ideal busca obter o máximo de potencialidade e agilidade durante o ciclo de vida do sistema.

Degradação da Arquitetura de Software

O ciclo de vida do sistema envolve 4 etapas distintas: lançamento, crescimento, estabilização e degradação. Um possível sinal de que o modelo está em fase de degradação é quando ocorre a conclusão de que para implementar uma mudança será necessário um grande esforço ou até mesmo motivar o redesenho de um componente ou da própria Arquitetura.

Do mesmo modo, para atender as solicitações dentro dos custos e prazos almejados são aplicadas decisões técnicas que afetam a capacidade do sistema ao longo do tempo (no famoso mindset: “feito é melhor que perfeito”). Neste momento entende-se que a capacidade do modelo foi reduzida.

Em outras palavras, devido a capacidade reduzida, o sistema irá reduzir sua potencialidade e agilidade. O custo de implementação de novas funcionalidades será crescente até o momento no qual os resultados tendem a zero.

Débitos Técnicos

A diferença entre o custo de implementação da funcionalidade com redução de capacidade (famosa “gambiarra”, “jeitinho”, etc..) contra o custo da implementação correta que amplia a capacidade do sistema é denominado de “débito técnico”.

Como resultado, novas funcionalidades associadas a uma implementação com débito ampliam este custo. Além do mais, cada funcionalidade torna-se um fardo para uma arquitetura incapaz de suportá-lo.

Consequentemente, quando o custo for insustentável irá exigir uma remodelagem do sistema. Portanto, evitar o débito técnico ao máximo deve ser objetivo nos ciclos evolutivos.

Redução da Entropia

Entropia reflete a “desordem” de um sistema. Um sistema com um grande acúmulo de débitos técnicos está em entropia positiva.

Da mesma forma, as pressões da área de negócios para a realização de entregas são uma força diretriz, quando não dominante, para as estratégias de planejamento e execução do trabalho.

Contudo, cada ciclo evolutivo é uma oportunidade única para reduzir esta entropia. Além disso, os benefícios desta redução podem ser enumerados nos seguintes pontos:

• Primeiramente, mantém a qualidade do código-fonte;
• Em segundo lugar, mantém o desejo de execução de um bom trabalho por parte da equipe. Em geral, nenhum desenvolvedor gosta de realizar um trabalho de baixa qualidade;
• Além disso, aumenta substancialmente a facilidade de manutenção e a capacidade de estender o sistema;
• Finalmente, deixa claro as inconsistências do sistema e mantém a equipe consciente das possibilidades de evoluí-las;

Veja neste link um artigo que explica o conceito de entropia no âmbito do software.

Conclusão

A evolução da Arquitetura de Software está intimamente relacionada ao seu ciclo de vida. Durante as diferentes etapas o objetivo final é potencializar as capacidades para entregas de funcionalidades cada vez mais ágeis e precisas.

Contudo, sua maturação envolve decisões críticas a respeito dos benefícios que poderão ser colhidos ao longo do tempo, bem como dos débitos que deverão ser “pagos”.

Portanto, a avaliação de como este “custo” será pago envolve uma simples pergunta: “o custo deverá ser pago agora, ou no futuro com juros e perdas?”.

Este artigo faz parte de uma coleção de artigos dedicados a analisar de forma reflexiva o papel da Arquitetura de Software. Clique aqui para acessar o artigo introdutório e links para os demais artigos.