BT

Melhores da InfoQ em 07: Os Dez Erros Mais Comuns em Arquitetura

por Niclas Nilsson , traduzido por Mauricio De Diana em 29 Out 2008 |

Esta notícia foi originalmente publicada em 12 de outubro e faz parte da coleção das melhores notícias de 2007 publicadas na InfoQ

Eoin Woods, um dos associados da IASA Fellows publicou um artigo sobre o que considera serem os dez erros mais comuns em arquitetura - erros sobre os quais muitas vezes se aprende da forma mais difícil. Abaixo estão alguns trechos curtos desses dez pontos:

  1. Escopo Descontrolado. "Este é o tipo de situação em que um simples sistema de viagens acaba incluindo também um conjunto de funcionalidades para pedido de reembolso de despesas, com consequências inevitáveis nos custos, cronograma e qualidade do projeto... Tem certeza que não há nenhuma necessidade de segurança além de um simples login? Uma vez logados no sistema os usuários realmente vão poder executar qualquer operação?"
  2. Não Formar uma Rede Abrangente. "Um erro que muitos de nós já cometemos é focar em apenas um pequeno grupo dos interessados no sistema – é clássico prestarmos atenção apenas no cliente (aquele que está pagando pelo projeto) e nos usuários finais."
  3. Apenas Focar em Funções. "…a menos que o sistema apresente toda uma gama de qualidades (como performance, segurança, manutenabilidade, etc.) é improvável que ele seja bem sucedido."
  4. Descrições Feitas com Caixas e Linhas. "Há duas razões pelas quais a gigantesca figura (única e completa) feita no Visio não funciona bem como descrição arquitetural: primeiro, ela tenta mostrar informação demais em uma única representação, e depois, ninguém sabe com certeza o que cada um dos diversos tipos de símbolos que você desenhou significam."
  5. Esquecer que o Sistema Precisa Ser Construído. "Coisas comuns a se observar relacionadas a construção do sistema incluem designs que os desenvolvedores ou testadores não entendem de fato, tecnologias das quais eles não são entusiastas ou não têm tempo para aprender, e novas tecnologias que ainda não possuem um bom suporte de ferramentas ou talvez imponham uma forma de trabalhar nova ou com a qual eles não estejam familiarizados."
  6. Falta de Precisão da Plataforma."…não é mais suficiente simplesmente dizer que você "precisa de Unix e Oracle" ao especificar sua plataforma. Você precisa ser realmente claro sobre as versões e configurações específicas de cada parte para garantir que você vai ter o que precisa. Isto vai permitir que você evite a situação em que não consegue fazer o deploy de seu sistema porque alguém fez um upgrade de uma biblioteca para uma parte da plataforma sem se dar conta de que isso significa que alguma outra coisa vai parar de funcionar;
  7. Fazer Suposições sobre Performance e Escalabilidade. "Comece a considerar performance e escalabilidade cedo, crie modelos para tentar prever valores de performance fundamentais e achar gargalos, e faça uso de provas de conceito a medida em que suas idéias de design vão se formando. Isso vai ajudar a aumentar a confiança de que não há problemas de performance e escalabilidade escondidos em seu design."
  8. Segurança "Faça Você Mesmo". "Um erro cometido em diversos sistemas ao longo dos anos é tentar colocar segurança no sistema usando tecnologia "caseira". Sejam algoritmos de encriptação inventados, um sistema de auditoria próprio ou todo um sistema de controle de acesso "Faça Você Mesmo", soluções de segurança desenvolvidas em casa raramente são uma boa idéia. Apesar de a maior parte de nós se achar capaz de fazer rapidamente um componente de segurança, normalmente estamos errados."
  9. Nenhuma Recuperação de Desastres. "O fundamental para conseguir recursos para implementar um mecanismo de recuperação de desastres para o seu sistema é quantificar o custo da indisponibilidade do sistema em cenários reais. Se você também conseguir estimar a probabilidade desses cenários acontecerem, você pode usar essas duas medidas para convencer as pessoas de que a recuperação de desastres é importante e assim justificar um certo orçamento para implementá-la."
  10. Nenhum Plano de Contingência. "Garanta que qualquer coisa que possa acontecer durante o deployment ou atualização do seu sistema tem um plano documentado, revisado e aceito para permitir voltar o ambiente ao estado anterior ao deployment."

Eoin Woods é um arquiteto de software e arquiteto empresarial no UBS Investment Bank.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Os Dez Erros Mais Comuns em Arquitetura by Paulo Trecenti

Ótimo artigo, poderiamos incrementar esta lista com muito mais erros, outra coisa que eu acredito que faça parte de uma boa arquitetura, são os "números" e os "por ques". Números para provar a real capacidade da arquitetura sugerida e para que ela é proposta, e uma falha muito grave é não responder aos "por ques"? Por que usar certa tecnologia, framework, api, protocolo de comunicação, fatoração, etc...? Por que, Por que Por que ???? Na verdade estas duas coisas são complementares.
Precisamos evoluir muito...

Re: Os Dez Erros Mais Comuns em Arquitetura by Felipe Rodrigues

Concordo com você Paulo... Questionar os motivos de se adotar um ou outra coisa é sempre muito importante, mas pelo que vejo nem sempre as pessoas se preocupam com isso. =(

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT