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:
- 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?"
- 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."
- 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."
- 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."
- 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."
- 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;
- 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."
- 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."
- 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."
- 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.