AP-G Quem precisa de um arquiteto de software? - Manual do Arquiteto de Software

Todo sistema de software possui uma arquitetura. Entretanto, ela nem sempre é planejada, tampouco idealizada por alguém que responde, pelo menos oficialmente, como arquiteto.

Gregory Hohpe ensina que há pelo menos quatro configurações possíveis para a atividade de arquitetura.

O arquiteto como “Ditador Benevolente”

Nessa configuração, cabe ao arquiteto definir o que precisa ser feito e ao time executar o que o arquiteto definir.

Embora aparentemente na contramão de estruturas modernas e ágeis, esta configuração pode ser necessária em times onde produzir o consenso é difícil. Geralmente, tais cenários são resultantes do excesso ou da falta absoluta da pressão por resultados. Ou ainda, por falta de equilíbrio de senioridade.

Por favor, deixe seu feedback aquix

No médio-longo prazo, times com uma cabeça, a do “ditador benevolente”, e diversos braços, o restante do time, são insustentáveis por promover comportamento medíocre.

Arquiteto como “membro do time”

Nessa configuração, o arquiteto assume a posição de orquestrador para as decisões mais importantes. Ele explicita e consolida opções com o time verificando sempre o atendimento dos objetivos do negócio, respeito a restrições e atendimento dos atributos de qualidade.

Geralmente, nessas configurações, há equilíbrio perceptível de senioridade na maior parte do time. As decisões nem sempre são tomadas rapidamente, mas, são sempre mais seguras.

Considerações?x

O maior risco, nessa configuração, é que o arquiteto passe a executar outras atividades, como escrever código, em demasia, deixando de cumprir seu papel primário.

Considerações?x

Arquitetura sem arquitetos

Nessa configuração, as atividades de arquitetura são diluídas entre os diversos membros do time, que assumem responsabilidade compartilhada pelos resultados.

Esse tipo de configuração só é possível em times com senioridade extremamente elevada, onde há consciência da natureza e da importância das atividades arquiteturais.

O maior risco, nessa configuração, é que o time negligencie aspectos como comunicação eficaz com outros stakeholders, migrando para outra configuração, “implícita” onde práticas arquiteturais simplesmente não são executadas.

Considerações?x

Arquitetura “implícita”

Nessa configuração, as atividades de arquitetura simplesmente não são executadas e a mesma “emerge organicamente” durante o processo de desenvolvimento. É comum em times alegadamente ágeis que acham práticas arquiteturais desnecessárias.

O resultado comum desse tipo de configuração é ver o time “fazendo outra fez” software que já fez no passado. Ou seja, reproduzindo soluções de projetos anteriores para problemas propostos no projeto atual.

Este tipo de configuração costuma ser o “gatilho” para adoção, em algum momento, do modelo com um “ditador benevolente”. Geralmente, quando o projeto sai dos trilhos.

Considerações?x