por produtos mais robustos. Tiveram ainda de fazer um extenso trabalho de desenvolvimento à medida: os requisitos de escalabilidade e desempenho do Twitter eram simplesmente demasiado exigentes para serem garantidos por produtos tradicionais de mercado.
Durante todo o período de implementação desta solução, e mesmo posteriormente até afinarem todas as agulhas, o Twitter continuou com falhas. Só em 2007 conseguiram estabilizar o sistema e garantir a usabilidade da aplicação. As mudanças arquitecturais não terminaram nessa data mas, desde então, têm sido motivadas por oportunidades de negócio emergentes e evoluções do próprio sistema.
Estas questões arquitecturais não acontecem só ao Twitter. Projectos milionários como o iPhone 4 sofreram
também da mesma doença. O iPhone e o Twitter conseguiram recuperar e vingar no mercado, mas houve outros que morreram à nascença e nunca chegaram ao grande público. E tudo devido às famosas falhas arquitecturais. Mas como podemos evitar erros do passado? Como podemos garantir que as nossas soluções são adequadas para sobreviver ao mundo real?
A verdade é que não existe uma silver bullet para este problema complexo. No entanto, existe um conjunto de boas práticas que podem ajudar. A mais importante é definir correctamente as necessidades do sistema. Citando Fred Brooks: "The hardest single part of building a software system is deciding precisely what to build".
Os visionários do Twitter falharam - talvez por não serem
astrólogos - na definição correcta do seu sistema. Novos projectos poderão evitar esses problemas garantindo que identificam correctamente, e na altura certa, os requisitos do sistema. Atributos como desempenho, escalabilidade e segurança não podem ser acrescentados a um produto que não foi desenhado para tal. Têm de ser pensados e incorporados na arquitectura de origem. Mas agora a pergunta é outra: será que a nova versão do Twitter foi pensada para suportar 500 milhões?