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.
Brilhante post, Phillip!
Fiquei pra trás na analogia com o McDonnald’s. Será que você anda lendo o Slow Leadership?
[]s
Bravo! Bravo! Ótimo post!
Caro Philip,
O problema não seria a arquitetura de referência virar uma imposição?
Ao invés de ser usada como guidelines vira uma norma a ser seguida? Como os Design Patterns: Se o cenário que você tem não é este, esta não é a melhor solução.
O que você acha?
[],
AC
@Tiago
É a questão do fast-food-tudo-pronto-na-caixinha.
@AC
Guidelines são legais mas eu nunca vi uma arquitetura de referência que não fosse imposta. Existem dois cenários que levar o senso comum à pedir uma arquitetura de referência:
1) Economizar
2) A maioria das aplicações de uma empresa é de um tipo X
Os dois são válidos e quando unidos podem resultar em guidelines interessantes, mas não em arquiteturas pré-definidas.
[]s
“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.” - Esse “tive” no texto denuncia que o arquiteto era você certo? :) ou foi só um erro de português?
Parabéns pelo artigo !!!
Foi a última notícia que tive, meu amigo arquiteto pode ter me dado notícias ;)
Você precisa vim “passear” em Brasília. Aqui é o paraíso das arquiteturas de referências, dos VOBOs, dos struts1 com ejb2. Quem quer fazer diferente disso sofre.
E como você falou arquitetura de referência = Arquitetura obrigatória.
Esses pelo menos estão desenvolvendo a arquitetura internamente, o que permite ao menos melhorar ela internamente. Existem empresas públicas COMPRANDO esses “frameworks de referência” (JCompany), além de pagar caro ficam amarradas ao fornecedor.
[...] http://philcalcado.com/2007/10/15/arquitetos-mcdonalds/ http://guj.com.br/posts/list/71466.java [...]
Excelente texto. A fé em arquiteturas de referência, bem como em frameworks que tentam capturar todo o universo presente (*e futuro*) da empresa é, de fato, um caso patológico de silver bullet.
E quando o arquiteto resolve colocar as cartas na mesa, ele vira o chato, o ogro que roubou o natal e a esperança de todas as pessoas de bem, que só queriam uma solução fácil para um problema difícil.
Eu diria que, nos cenários apresentados, o problema nem é (falta de) diálogo, e sim político - mas isso é quase chover no molhado…
[...] Não são só arquiteturas que sofrem com padronização desnecessária, entrevistas também devem ser desenhadas de acordo a situação, especialmente com o que se espera encontrar. [...]
[...] Há poucos dias atrás falamos aqui sobre arquiteturas de referência e seu efeito danoso. Geralmente quando alguém tem à frente um desafio desse ele logo pensa em um modelinho que mostra obriga o uso de uma meia dúzia de frameworks e padrões (clássico moderno: Struts/JSF e JPA, clássico vintage: Struts 1.1 e EJB/DAO). Para melhorar ainda é incorporado um conjunto de classes “utilitárias” feitas com práticas que talvez tenham servido para um projetinho piloto mas hoje em dia só atrapalham. [...]
Muito boa!!!
Caiu certinho na empresa onde estou.
Mi pergunto…
Será que os caras que idealizam este tipo de coisa não possuem uma visão um pouquinho mais aberta!!!
[...] todas estas formas de evolução. Obviamente que nenhuma destas ferramentas oferece nada parecido. Nós já vimos antes sobre o problema de se estabelecer uma arquitetura única para tudo, o problema com estas ferramentas é muito pior. Quando se define uma única arquitetura para todos [...]
[...] Se você ainda não tem conhecimento para utilizar conceitos mais rebuscados se mantenha simples e elegante -e elegante para mim significa ter boas primitivas e pouquíssimas exceções. Claro que sua arquitetura não vai servir para todas as coisas mas lembre-se que arquiteturas devem ser pensadas de acordo com o projeto, não existe arquitetura de referência. [...]
[...] uma vez por toda que não existe uma arquitetura de referência ou receita de bolo para desenvolver sistemas, cada sistema possui suas necessidades e [...]
Prezados, acredito que o problema não é a adoção de framework é o tempo que gasta para juntar esta parafernalha em nome de “padrões de projetos” ai diferente de “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”, passa pelo purísmo do melhor, o tempo passa, nada acontece e a culpa são das ferramentas, ao passo que tinham que ser de quem as implementam…
Davince,
Não deu para entender muito bem o que você quis dizer. Pode tentar explicar novamente com outras palavras?
[]s