Erros primários que um arquiteto não pode cometer

[Novo endereço: leandrosilva.com.br.]

Assumir o boné de arquiteto em um projeto de software é uma tarefa que requer maturidade, muito além do simples conhecimento técnico, pois boa parte do sucesso de um projeto de software depende de decisões arquitetônicas.

Presto consultoria nessa área há algum tempo, e não foi uma nem duas vezes que vi pessoas cometerem erros primários ao assumirem esse boné – ao ponto de quase levarem projetos à ruina. Baseado nessa experiência, quero citar cinco erros primários que um arquiteto pode cometer ao ignorar:

1- O time de desenvolvimento

Não, desenvolvedores não são como apertadores de porcas e parafusos de linha de produção. Se você ainda acredita no conto de fadas do processo fabril para desenvolvimento de software, sinto lhe dizer que isso não passa de balela. A verdade é que desenvolvimento de software é um processo criativo, mais humano que mecânico.

Assim, é preciso levar em conta que cada time de desenvolvimento é diferente do outro, tendo qualidades e deficiencias que de maneira alguma podem ser ignoradas. Ao contrario disso, devem ser colocadas sobre a mesa e ponderadas antes de quaisquer decisões arquitetônicas. Ignorar isso pode ser a ruina do projeto.

Portanto, não basta somente o “sr arquiteto” dominar as técnicas e tecnologias escolhidas para o projeto. É preciso que todo o time de desenvolvimento também esteja apto a operacionalizar cada decisão com qualidade.

Um bom arquiteto precisa saber trabalhar com o conhecimento e a experiência do time. Precisa constantemente promover a evolução técnica do time, mas também saber abrir mão da última versão daquele framework mais legal de todos, quando o time ainda não está apto a usá-lo e não há tempo hábil para capacitação.

Outra coisa fundamental é tornar o time de desenvolvimento participante nas decisões arquitetônicas do projeto. Isso torna o time mais convicto das decisões e também mais comprometido com a sua operacionalização.

2- O escopo do projeto

Não é incomum ver arquitetos querendo conceber soluções que vão atender os requisitos de hoje e os da próxima década. Isso é péssimo, porque leva a elocubrações sem fim. Além, é claro, do iminente risco de construir uma arquitetura frankenstein.

“Ah! Mas e se daqui a um ou dois anos vocês quiserem que o sistema de pagamento possa também receber pagamentos por moeda estelar? Será que não seria melhor se modelassemos algo mais flexivel?” – ah meu Deus!

Tenha bem claro qual o objetivo do projeto, onde ele começa e onde ele acaba. Não fique aquém, nem vá além.

Ah! E não se esqueça de deixar também o time de desenvolvimento bem ciente desses limites.

3- A compatibilidade

Não estabelecer claramente as versões de sistema operacional, banco de dados, IDE, frameworks e bibliotecas, com as quais o software em desenvolvimento deve ser compativel é roubada. Porque o que funciona na versão 1.0 do framework XPTO, talvez não funcione na versão 2.0. Quem garante? Eu que não me atrevo!

Já enfrentei tantos problemas trabalhando em projetos onde não existia essa prática que até me dá arrepio pensar nisso. Você debuga pra cá, debuga pra lá, e quando vai ver, foi um bendito JAR que foi mudado e ninguém te avisou, ou mesmo se preocupou em saber se quebraria o que você fez. Pior ainda quando isso acontecia no momento da implatação do produto final. Urgh!!!

Agora, como fazer isso de maneira eficiente? Bem, para o caso de bibliotecas e afins, sugiro que você dê uma olhada no Artifactory, ele serve de repositório para o Maven. E para sistema operacional, banco de dados, IDE, e outros elementos de infra, um quadro na parede já resolve bem o problema.

4- O design evolutivo

A chave para o design evolutivo é fazer o mais simples possível e ir refatorando depois, conforme a necessidade. Sim, o estado da arte nunca acontece na primeira implementação; tentar fazer isso pode leva-lo à ruina.

Seja prático. Primeiro tenha algo funcional; depois, evolua.

5- As opções de ferramentas

Como se diz “se você só tem um martelo, tende a enxergar todos os problemas como um prego”. Isso é perigoso, porque te faz desperdiçar tempo e dinheiro – e ainda conceber soluções burras.

Faz um bom tempo que o Phillip escreveu este post e ele ainda é muito atual. Infelizmente. Sim, infelizmente, porque ainda tem muita gente que se recusa a ter mais do que um martelo em sua caixa de ferramentas.

Trabalho com Java há muito tempo, mas hoje esta não é a única ferramenta em minha caixa. Há tantas ferramentas boas no mercado, porque ignorar isso?

Há ainda muitos outros erros, certamente…

Que tal você registrar alguns nos comentários deste post?

Valeu!

5 Respostas para “Erros primários que um arquiteto não pode cometer

  1. Belo post !
    Eu gostaria de registrar o caso do Arquiteto de Papel … este realmente pega o sentido da palavra Arquiteto e fica desenhando todo o sistema em UML e diagramas … isto é muito bom né, afinal os diagramas sempre “compilam” e nunca dão erro !
    Depois de um ano ou mais, descobrem que não dá pra reaproveitar quase nada da “planta” do sistema desenhada pelo Arquiteto, aliás, falando em “planta” já lembra Engenharia Civil também né …

    Bom é isso ! Dei o meu pitaco !
    Valeu!

  2. Esse tipinho de papel é o que mais existe por ai… hehehe

  3. Que nada, arquiteto de papel eh espécie em extinção. Através de mutações eles evoluíram! Agora usam ferramentas CASE😉

  4. Po Leandro.. esqueceu de um super importante! Não falou nada dos Xiitas!?!? “Eu é que ter perrrgunto!!!!”. Vc sabe que nós já sofremos muito com esse tipo.. Vale uma versão 2.0 do post não vale?? hauahuah

    []’s

  5. Xiitas? Sim, tinha me esquecido dessas figurinhas… Acho que vai ter que ter uma versão 2.0 sim, totalmente dedicada a eles!🙂

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s