Disciplined Agile 2.0: Arquitetura Ágil de Sistemas

A arquitetura de sistemas fornece uma base para a construção de um sistema. Através do modelo arquitetural é possível entender definições como tecnologia, padrões de projeto e conceitos utilizados, além da infra-estrutura necessária para a sua implementação e implantação.

Na definição da arquitetura muitos fatores são considerados. Seguem alguns exemplos:

•  O sistema deve funcionar em rede local ou pela internet?
•  Qual o perfil dos usuários que irão acessar o sistema?
•  Os usuários utilizarão tablet ou celular?
•  Será necessário acesso assíncrono de dados?
•  Quantos usuários irão acessar o sistema simultaneamente?
•  A empresa possui um data center? Quais sistemas operacionais são utilizados pela empresa?
• Quais sistemas operacionais são utilizados pelos usuários do sistema?
• Quais outros dispositivos são utilizados pelos usuários do sistema?
• Qual a criticidade do projeto e a expectativa de prazo do cliente?
• Trata-se de um sistema isolado ou o mesmo deve ter os dados integrados com outro(s) sistema(s)?

De acordo com o Disciplined Agile,  é possível utilizar uma abordagem ágil para a arquitetura de sistemas. Na fase de iniciação é necessário obter uma visão geral dos requisitos e, com base nestas informações, obter uma visão geral da arquitetura.

Com o conjunto de informações obtidas é possível responder questões críticas do projeto como escopo, estratégia técnica, cronograma e custo estimados.

Na fase de iniciação, além de obter um direcionamento para a equipe técnica, considerando o ponto de vista de arquitetura de sistemas, o arquiteto deve fazer uma analise de riscos técnicos e não se preocupar com a especificação completa da arquitetura.  

A arquitetura do sistema deve ser construída sob demanda, durante as iterações. Assim, ela surge ao longo do tempo, em incrementos, possibilitando melhor compreensão da equipe e reduzindo os riscos técnicos do projeto

Uma alternativa a arquitetura ágil é definir a mesma completamente antes da implementação.  Nessa abordagem pode existir uma expectativa de que a implementação será mais assertiva se todos estiverem  cientes da arquitetura completa estabelecida.

Quando essa abordagem é utilizada, normalmente, as mudanças não são bem vindas e, talvez, esse seja uma das principais dificuldades de se trabalhar com a mesma.

No início do projeto não é possível prever todas as situações, embora a visão inicial tenha que ser bem elaborada.  A arquitetura pode sofrer mudanças devido a fatores externos como, por exemplo, a necessidade de acessar o sistema por celular em determinadas situações, que antes não era uma necessidade do stakeholder.

Segundo o Disciplined Agile,  a responsabilidade pela arquitetura do sistema é de todos os membros da equipe, embora isso seja mais difícil no caso de equipes geograficamente distribuídas.

O Architecture Owner é um profissional com boa experiência técnica e que atua como facilitador na tomada de decisões sobre a arquitetura. No caso de não haver uma opinião comum entre os membros da equipe, o Architecture Owner é o responsável pela decisão final.

Um Architecture Owner deve possuir um bom entendimento sobre o domínio do negócio e possuir as habilidades necessárias para comunicar a arquitetura aos desenvolvedores.

O Disciplined Agile possibilia trabalhar de forma escalável em diversos aspectos, inclusive na arquitetura do sistema.  Vários times pequenos podem trabalhar de forma alinhada em um grande projeto.   Nesse cenário, um time de Architecture Owners é responsável por garantir as definições de arquitetura, a padronização e compatibilidade das entregas de cada equipe.

Figura 1 - Escalabilidade em times ágeis

O Disciplined Agile possibilia trabalhar de forma escalável em diversos aspectos, inclusive na arquitetura do sistema.  Vários times pequenos podem trabalhar de forma alinhada em um grande projeto.

Para trabalhar com uma equipe de arquitetura escalável pode-se seguir uma das seguintes abordagens:

• Orientada a arquitetura: as equipes trabalham no desenvolvimento de componentes e subsistemas. A estratégia funciona bem quando a equipe possui uma arquitetura de alta qualidade (com baixo acoplamento e alta coesão) e com as interfaces entre os componentes previamente identificadas.
  
  
• Orientada a funcionalidade: seguindo essa abordagem, cada equipe implementa uma funcionalidade significativa para o stakeholder por vez.  Pode ser aplicada em cenários onde existe alto acoplamento e necessidade de trabalhar com muitos arquivos de código-fonte, onde existe alto risco de conflitos nos arquivos utilizados pelas equipes.

• Open source: subsistemas e componentes são desenvolvidos dentro do conceito de código aberto.  Geralmente é aplicado em produtos que são amplamente utilizadas por muitas equipes.  Esta estratégia exige que você a adotar ferramentas e processos que suportam abordagens de código aberto.

• Combinada: a maioria das equipes ágeis em escala vai combinar as três estratégias anteriores, conforme a necessidade.

Seja qual for o cenário no qual a equipe se encontre, trabalhar com arquitetura de forma ágil sempre vai diminuir os riscos técnicos do projeto e possibilitar melhores resultados.