Os 7 Mandamentos do Arquiteto de Software

Há algum tempo atrás, quando eu estava preparando material para o curso de Arquitetura de Software do IBTA, eu encontrei um artigo na Internet que falava dos 10 mandamentos para o arquiteto de software. Achei bem interessante o ponto de vista do autor e levei os 10 mandamentos para o meu curso para ilustrar as diferentes visões do que deveria ser um arquiteto.

O artigo mencionava os seguintes mandamentos:

  1. Se não for simples, não vale a pena.
  2. Se não for estável, não vale a pena.
  3. Se não for suportável, não vale a pena.
  4. Jamais justifique a tecnologia pela tecnologia.
  5. Seja flexível.
  6. Questione tudo.
  7. Não culpe o fabricante da tecnologia pelos erros que você cometeu.
  8. O ótimo é inimigo do bom.
  9. Faça uma trégua com a equipe de infra-estrutura.
  10. Não reinvente a roda.

(http://www.enterpriseguys.com/Artigos.aspx?ColunistaID=29&id=40 )

Concordo com todos os pontos acima, mas fiquei pensando quais seriam os mandamentos que eu escreveria. Quais seriam as principais práticas que qualquer arquiteto deveria conhecer, entender e praticar. Foi nesse misto de curiosidade e um pouquinho de inveja que resolvi escrever esse artigo com os 7 mandamentos que considero vitais para um bom profissional de arquitetura.
Vamos lá!

1: Seja Orientado a Valor

Onde “valor”não significa a última onda em termos tecnológicos. Acho que um dos grandes problemas das áreas de arquitetura das empresas é colocar o técnico na frente de negócio. Eu concordo 100% com a frase: “jamais justifique tecnologia pela tecnologia”.

Todos os projetos de software existem com um plano de negócio por trás. Ou seja, ele possui um propósito claro de gerar um valor financeiro dentro de um prazo que costuma variar de 3 a 5 anos. Todas as decisões de arquitetura desse sistema deve enfocar nisso: trazer o retorno financeiro esperado e projetado para a empresa. O propósito não é ratificar os blue prints de mercado, massagear o ego dos papas da Engenharia de Software e nem resolver todos os problemas que ainda não existem. “Mas e se tal coisa acontecer um dia? Se a gente criar 8 camadas lógicas, poderemos abstrair a complexidade dessa mudança na sexta camada…”. E lá se vai prazo e custo…

2: A Beleza Está na Simplicidade

O seu objetivo como arquiteto não deve ser criar modelos, diagramas e códigos-fonte que fariam os rascunhos de Einstein ao desenvolver a teoria da relatividade parecerem brincadeira de criança. Lembre-se que pessoas mais juniores que você (implementadores) irão precisar entender e construir um sistema baseado nas suas decisões. Por várias razões: quanto mais simples melhor! Várias pessoas terão contato com o sistema ao longo do tempo, desde a criação até manutenção e evolução. É papel do arquiteto garantir o entendimento adequado do sistema para essas pessoas.

3: Arquitetura é 5% Inspiração e 95% Transpiração

Não adianta tomar uma série de boas decisões, criar um documento de arquitetura super completo e depois virar as costas para o projeto durante a construção deste. Vai dar errado! Pessoas vão interpretar erroneamente o que você escreveu, não vão conseguir fazer algumas coisas determinadas por você ou simplesmente vão ignorar todos os seus direcionamentos para ir pelo caminho mais simples… que pode levar a grandes problemas.

Invista tempo na passagem de conhecimento. Invista tempo averiguando junto à equipe se as coisas estão em ordem, crie scripts para fazer inspeções automáticas, teste… se envolva!

4: Seja Cuidadoso com o Aspecto Funcional, Seja Paranóico com o Não-Funcional

Entendo perfeitamente preocupações relacionadas a aspectos funcionais do sistema que está sendo desenvolvido. Precisa mesmo! Agora… muito cuidado principalmente com os requisitos não-funcionais. E por um simples motivo: eles costumam ser horizontais a todo o sistema. Isso significa que falta de cuidado e atuação arquitetural nesses pontos pode significar um impacto violento em todo o sistema, podendo chegar a refactoring, re-trabalho ou re-construção de partes significativas dele.

Se houver problemas sérios de performance e chegar a conclusão que o banco de dados está muito normalizado, o banco inteiro pode ter que sofrer alterações, e consequentemente a aplicação. Se o sistema está fazendo muito uso de sessão e descobre que, por questão de alta disponibilidade, vai haver balanceamento de carga sem afinidade de IP, uma fatia significativa do código terá que ser revista. Enfim, todo cuidado é pouco.

5: Acredite no Plano Que Você Está Inserido… Sob Todos os Aspectos

Olhe o plano do projeto no qual você é o arquiteto e acredite nele. Não apenas do ponto de vista de arquitetura, mas sob todos os pontos. De nada vai adiantar o sistema estar bacana do ponto de vista arquitetural mas possui muitos defeitos, estar atrasado, não atender o negócio etc. Seu foco sempre deve ser a parte arquitetural, mas nunca deixe de dar feedbacks para outros membros da equipe (gerentes de projeto, testers, implementadores etc) se você enxerga algum risco para o seu projeto que seja relevante ser compartilhado.

O projeto só será de sucesso se todos os aspectos forem bem. Nunca lave as mãos.

6: Faça Gestão de Riscos na Medida Certa

O arquiteto é o principal responsável por fazer gestão (identificação, planejamento e resolução) de riscos técnicos. Mantenha sempre tudo no seu radar. Crie o instrumento que você achar adequado para catalogar riscos e planos de ação e mãos à obra.
Importante: fazer uma boa gestão não significa ficar procurando pêlo em ovo. Se você não tiver um bom critério na gestão de risco, a única coisa que você vai conseguir é deixar todo mundo louco (principalmente o gerente de projetos) com os trocentos riscos que insistentemente você faz questão de ficar levando em todas as reuniões de status.

7: Comunicação é Tudo

Como é importante se comunicar bem! Eu diria que mais da metade dos problemas que vejo são, de alguma forma, derivados de problemas de comunicação.

Saiba apresentar bem a sua arquitetura, para clientes, áreas de negócio, implementadores e outros arquitetos. Note que a linguagem para cada um desses públicos é completamente diferente uma da outra. Saiba abstrair termos técnicos ao conversar com público executivo, reforce aspectos de custo e prazo (provavelmente o principal interesse dele). Saiba usar termos simples para que os implementadores entendam as suas decisões e direcionamentos técnicos.

Comunique pendências, transmita com clareza suas necessidades, seja cordial com todos os envolvidos… Enfim, são infinitas as orientações que podem ser dadas dentro desse grande guarda-chuvas que é a comunicação. Sugiro uma forte reflexão do que pode ser feito para evoluir nesse assunto.

Esses são os meus 7 mandamentos. Certamente muito mais fácil de colocar num artigo do que conseguir aplicar no dia-a-dia, mas essa é a vida na cidade grande.

Abraços,
Daniel V.