O gap arquitetural

November 3rd, 2009 § 0 comments

Desde que comecei a trabalhar com uma forma ou outra de metodologias ágeis, um dos assuntos que sempre me causou reflexão foi a questão de como lidar com arquitetura em um ambiente ágil. Obviamente, eu não sou o único que se questiona sobre isso: a discussão em torno de Big Design Up Front é tão velha quando a própria indústria. Existe uma polarização imensa sobre o assunto e é bem raro encontrar alguém que tenha desenvolvido alguma idéia que se encaixe no meio do caminho.

De fato, proponentes de metodologias ágeis geralmente gravitam em torno do que se comumente denomina design emergente, ou seja, a criação e concepção de conceitos arquiteturais–especialmente os não funcionais–ao longo do processo de amadurecimento da própria solução.

Duas coisas me levaram a repensar sobre o assunto nos últimos dias.

A primeira foi participar de uma palestra dada por ninguém menos do que Fred Brooks. Brooks é um dos autores mais influentes sobre a questão de arquitetura e design e eu sempre tive uma concordância forte com seus pontos de vista, especialmente no que tangem à necessidade de centralização de arquitetura como fonte de integridade conceitual em uma solução. O Mítico Homem-Mês toca profundamente nesse questão–de fato o livro pode ser considerado uma coleção de ensaios em torno desse tema–e Brooks sempre volta-se para essa necessidade de design arquitetural prévio para garantir soluções sólidas.

A segunda coisa que me levou a pensar sobre o assunto foi um tweet de Brian Foote, reportando da OOPSLA:

When we extol the benefits of architecture emerging in agile, we are really saying developers are better architects than Architects. #oopsla

Foote, conhecido pelo seu trabalho com Joseph Yoder, Big Ball of Mud, em que descreve a estruturação impensada de sistemas resultando em algo impossível de manter e impossível de se confiar, está correto em sua avaliação.

É claro que, nesse ponto, muita gente deve estar pensando que eu sou um elitista, que, de uma forma ou outra, considero arquitetos melhores do que desenvolvedores. Meu cargo atual pode até dar a entender isso–sou um gerente de arquitetura e engenharia de software na empresa onde trabalho–mas esse não é caso.

De fato, se eu tivesse hoje que me descrever em um currículo, eu teria bastante dificuldade de me conceituar em uma categoria qualquer. Eu poderia colocar que sou um desenvolvedor, já que faço isso. Também poderia colocar que sou um arquiteto, igualmente válido para o que faço. Poderia recorrer aos tradicionais programador ou analista de sistemas. A verdade é que sou tudo isso.

Para mim, um arquiteto não é alguém que atingiu um estado de santificação tal que pode abandonar os conturbados e lamacentos meandros da programação e recolher-se em sua torre de marfim para dispensar sua sabedoria sobre as massas menos iluminadas. Antes, tenho certeza de que a maioria dos meus colegas que se descrevem como arquitetos concordariam que arquitetura é mais uma questão de atuação e experiência do que de grau ou de talento nato. Eu não trabalharia com um desenvolvedor que não fosse capaz de responder por sua arquitetura e também não trabalharia com um arquiteto incapaz de codificar um algoritmo qualquer. Tentar extrair uma coisa da outra seria uma violação das premissas.

Voltando ao ponto, é justamente aí que entra a figura que Brooks descreve, o arquiteto-chefe que, por experiência, treinamento e sensibilidade adquiridos na prática, é capaz de guiar um sistema à integridade conceitual necessária para o seu bom desenvolvimento.

O que resolve, finalmente, para mim, a questão de emergência em metodologias ágeis. Eu acredito que, sim, deve haver arquitetura propriamente dita em qualquer projeto, mesmo os que subscrevem a metodologias ágeis e acho que isso nunca esteve fora da visão dos criadores das mesmas. Antes, essa é uma visão equivocada do que deve ou não emergir dentro das mesmas, que é a solução em si.

Arquitetura, por definição, é algo que precisa ser feito antes até um certo ponto, mesmo que depois sofra as mudanças necessárias por sua própria evolução gradual. Ela não pode ser estática–exceto em circunstâncias especiais que normalmente quase nenhum desenvolvedor encontrará ao longo de sua carreira–mas também não pode ser completamente ad hoc já que isso seria pouco mais do que pensar apenas no que está imediatamente adiante, sem se preocupar com os temas maiores que podem afetar o trabalho.

Em última instância, a arquitetura então não é necessariamente emergente: a solução o é. E por solução aqui, eu entendo o conjunto completo representado pelo produto, sua arquitetura, seu desenvolvimento e sua transição em produção. A responsabilidade de um arquiteto é traduzir o backlog, ou seja qual for seu equivalente, em temas conceituais que possuem integridade em conjunto e que levam a um desenvolvimento das características do software a seu tempo e com as suas necessidades atendidas.

Esse é um gap que fica claro na maior parte da discussão sobre arquitetura e metodologias ágeis e que precisa ser tratado mais freqüentemente pela literatura e seus proponentes.

Para finalizar, essa é apenas uma visão rápida do que tenho pensado nos últimos tempos sobre o assunto. Espero ter deixado minha visão um pouco mais clara do que estava em discussões passadas aqui no blog. Como sempre, comentários e discussões adicionais são sempre bem-vindos.

Tagged

Leave a Reply

Your email address will not be published. Required fields are marked *

What's this?

You are currently reading O gap arquitetural at Superfície Reflexiva.

meta