Fragmental

Estava eu lendo sobre um novo framework criado por alguma agência governamental de um estado qualquer. Geralmente eu não resisto e faço algum comentário sobre a utilidade de um framework que não traz nada de novo ou de bom e gasta dinheiro público (dinheiro público o caramba, seu dinheiro!) para isso mas desta vez me contive só em olhar os tutoriais da ferramenta, que sempre resulta em bons anti-exemplos para postar aqui.

Não me entendam mal, eu já trabalhei para empresas públicas e aquelas que andam na zona cinza entre empresas públicas e privadas e já vi muita coisa boa sendo feita lá. O problema de empresa pública hoje é o concurseiro profissional, esta praga que assola os cofres públicos atrás de cargos que pagam bem (quem nunca viu algum informata aprendendo direito para passar em provinha?) e depois pulam para outro que paga melhor. Enfim, o problema não é ser um órgão público, poderia ser numa empresa privada (a diferença é que se você considerar como uma empresa privada tem que considerar que você é acionista que investe muitos-% do seu salário nela e deveria ter algum resultado).

O ponto inicial é que arquiteturas de referência são um conceito falido. Ter guias arquiteturas, modelos, sugestões é uma coisa, impor uma arquitetura única é outra. O Luca já deu diversos motivos para não fazer este tipo de coisa e eu lembro de um projeto que participei há alguns anos atrás em uma grande empresa que utilizava esta técnica.

Toda a parte de logística da empresa, um mega-departamento com seu próprio vice-presidente, utilizava um framework que foi definido por uma equipe arquitetural. Eu conheci o arquiteto em questão e não acho que ele seja um mau profissional, pelo contrário é bem talentoso. O problema é o diálogo:

- Fulano, estamos cansados de gastar dinheiro nesta arquitetura mainframe, precisamos migrar para Java logo.
- Ok, falei com a consultoria XYZ e eles alertaram para o fato de que não existe ‘desenvolvimento Java’, você tem que escolher uma plataforma diferente a cada projeto!
- Mas @#$#! Se eu vou comprar Java eu vou comprar algo que sirva para tudo que venhamos a fazer. Eu quero uma solução, Fulano, se vira!

(…)

- Arquiteto José, precisamos definir a tecnologia utilizada.
- Mas precisamos testar…
- Cara, a gente paga você pra tomar decisão, aprende isso de uma vez. Sabe o projeto da agenda telefônica? Aquele que não tem a menor importância? Então, pega ele pra fazer, junta seus melhores programadores e faz uma prova de conceito de uma arquitetura.

E lá vai o arquiteto fazer um projetinho sem valor nenhum com a tal tecnologia. O projeto invariavelmente é um sucesso mas se falhar ninguém liga. Daí agora todas as aplicações usam o framework.

E esquecemos o que há de mais importante na arquitetura. O engenheiro analisa a obra do ponto de vista técnico, o arquiteto analisa de diversos pontos de vista. Lembro de um caso recente onde um amigo precisou criar um sistema complexo rapidamente. O sistema exigia uma complexidade grande e deveria ser feito em pouquíssimo tempo com uma equipe de desenvolvedores junior. O arquiteto viu o cenário como um problema e traçou um plano: criou uma camada de abstração forte (quase uma DSL) que permitia aos programadores desenvolver rapidamente mesmo sem muito conhecimento sobre Java. Quando o projeto foi bem-sucedido apareceu o gerente de tecnologia maravilhado! Ele queria adotar essa prática em todos os projetos, minimizando drasticamente custos e tendo sistemas prontos na data. Bala de prata.

Este arquiteto em questão se negou a fazer parte do grupo que definira o novo framework. Experiente do jeito que é ele sabia que uma arquitetura que dá certo em um projeto não necessariamente vai dar em outro e ele não apostaria sua carreira e prestígio profissional num projeto furado desses. Como era consultor ele foi remanejado para outro cliente e a última notícia que tive da empresa é que ela criou seu framework com Velocity, Struts e JDBC, com uma versão em EJB 2.1 -nenhum projeto com este framework foi um sucesso até agora.

Ainda que o projeto que originou a arquitetura de referência tenha sido muito complexo e um sucesso absoluto isso não quer dizer que outros com esta arquitetura serão. Não é porque objetos foram feitos para arquiteturas do tipo Domain Model que ela é a mais adequada sempre, não é porque EJBs são o mecanismo padrão de distribuição que ele deve ser utilizado para qualquer RPC.

Existe um paradoxo nas arquiteturas de referência: para se ter uma boa arquitetura (de referência ou não) é necessário um bom arquiteto mas a primeira coisa que um bom arquiteto vai dizer é que arquiteturas de referência são uma péssima idéia.

This entry was posted on Monday, October 15th, 2007 at 6:21 pm and is filed under arquitetura, comunidade, engenharia, gerencia, guj, java, metodologias, programando. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.