Uma boa Arquitetura de Software é um dos fatores chave para obtenção de sucesso nos projetos de desenvolvimento. A importância do seu papel e a influência positiva no projeto é representada pelos seguintes tópicos:

Longevidade

A maior parte das arquiteturas possuem um tempo de vida maior do que a equipe responsável por sua criação. Estimativas consideram que uma arquitetura possui um tempo de vida de 12 a 30 anos, enquanto o tempo de vida de um desenvolvedor ( tempo no qual o desenvolvedor está atuando no mesmo sistema) varia de 2 a 4 anos.

Estabilidade

Arquiteturas bem desenhadas com o objetivo de suportar um sistema ao longo prazo são estáveis, ou seja, permitem que sejam aplicadas pequenas mudanças estruturais para atender inúmeros ciclos contínuos de evolução, reduzindo assim o custo total de propriedade (CTO).

Portanto, uma Arquitetura de Software estável fornece uma base importante para os desenvolvedores efetuarem um trabalho focado na entrega de valor ao invés de trabalhar em algo que esteja sempre mudando.

Facilidade de Mudança

A arquitetura do sistema determina a natureza de mudança dentro do sistema, criando as percepções de “fácil” ou “difícil”. Neste sentido, o conceito de “fácil” está relacionado com um estado de mudança que traga satisfação ao cliente ou permita adicionar novas funcionalidades com pouco esforço relativo.

Rentabilidade

Uma boa Arquitetura de Software é rentável – a empresa que faz uso dela consegue mantê-la a um custo aceitável. Se o custo for alto, a tendência é que seja abandonada.

Por outro lado, ser rentável não significa que ela seja “bela” ou “elegante” (ex: a família de produto Windows é um exemplo de produto rentável no qual a arquitetura é questionável).

Porém, isto não é motivo para que uma Arquitetura de Software seja má planejada. No longo prazo, arquiteturas simples e elegantes tendem a ser a base de soluções rentáveis.

Estrutura Social

A Arquitetura de Software trabalha a favor do time responsável por sua criação e manutenção. Ela deve potencializar a força da equipe e, as vezes, diminuir as suas fraquezas.

Não importa a tecnologia utilizada, ela será base para moldar o trabalho da equipe e irá direcionar atividades como políticas de treinamento e habilidades necessárias para contratação de profissionais.

Como visto anteriormente, o ciclo de vida da Arquitetura de Software ultrapassa o ciclo de vida das pessoas envolvidas em sua criação e manutenção, estes efeitos na estrutura social da empresa podem durar décadas e influenciar na cultura de trabalho.

Custo de Mudança

Uma das perguntas mais difíceis de ser respondida é: quando se deve substituir uma arquitetura antiga por uma nova?

Diversos fatores influenciam nesta resposta e é impossível estabelecer um conjunto de regras ou checklist para determinar quando deve ocorrer a mudança: há custos associados a sustentação do modelo antigo, atendimento das necessidades contínuas dos clientes e negócios, movimento de mercado dos competidores, etc.

A regra de ouro sobre esta decisão está em “seja cuidadoso”: a prática geralmente será mais difícil do que foi planejado e haverá diversos custos implícitos na mudança.

Segundo Luke Honmman, do ponto de vista econômico, se há uma equipe dedicada, com pessoas experientes e com um processo de desenvolvimento bem estruturado, o custo de criação da primeira versão de um novo modelo de arquitetura é em torno de 20% a 30% do custo total da arquitetura antiga.

A realidade é que, dependendo da qualidade da equipe e da complexidade da solução, este custo pode ficar entre 40% a 60% do valor investido no modelo atual.

Fronteiras Bem Definidas

Durante o processo de modelagem a equipe decide inúmeras vezes “o que” e “onde” devem ser construídas as funcionalidades ou utilizadas certas tecnologias. O ideal é que estas “fronteiras” estejam alinhadas com a necessidade do negócio.

Porém, em mercados ou soluções de negócio emergentes a curva de aprendizado da arquitetura acompanha a curva de aprendizado do negócio. Neste cenário, escolhas ruins podem criar débitos técnicos que nunca serão recuperados.

Sustentabilidade

Este tópico sintetiza todos os apresentados anteriormente: uma arquitetura que leva em consideração todos os elementos mencionados acima cria um modelo sofisticado, difícil de duplicar e com uma vantagem competitiva sustentável.

A entrega de valor é contínua, inclusive em aspectos técnicos que afetam a percepção de qualidade por parte dos usuários: usabilidade e performance da solução.

Conclusão

Nem todos estes tópicos possuem o mesmo grau de importância dentro de um projeto, porém todos eles são necessários e devem estar presentes ( de maneira explícita ou não) no modelo de software a ser concebido.

Nos artigos anteriores foi apresentada uma introdução a Arquitetura de Software do ponto de vista técnico (leia aqui) e uma visão alternativa alinhada com expectativas das pessoas envolvidas na sua construção e uso (leia aqui).

Este artigo encerra um ciclo conceitual que será um direcionador para as atividades práticas de construção. No próximo artigo serão apresentadas as principais forças que direcionam a elaboração de um modelo de Arquitetura de Software. Até mais!!!