Artigo de opinião de Adrian Anacleto publicado no Cronista Comercial em 14/06/2011, edição impressa
Arquitetura de software: o negócio da qualidade em TI
Arquitetura na prática. Pense, rapidamente, em uma empresa cujas aplicações caem, funcionam lentas ou têm dados roubados. Com certeza você encontrou vários exemplos. Isso ocorre com frequência e é mais comum do que parece.
Os usuários de sistemas costumam evidenciar no uso cotidiano algumas questões de qualidade dos sistemas, programas ou aplicações. Por trás das expressões ou reclamações mais comuns que costumam fazer, podemos encontrar referências a atributos de qualidade de uma aplicação de software. Ao dizer: a aplicação está lenta, fala-se de performance; se ouvimos a aplicação caiu, o atributo de qualidade referido é disponibilidade; e se alguém diz não entendo esta aplicação, é muito complexa, está falando de usabilidade. E poderíamos seguir citando exemplos, porque as aplicações têm centenas de atributos de qualidade; entre os mais famosos estão: segurança, facilidade de manutenção, de modificação, de testing e muitos outros. Estes se encontram definidos por normas e padrões de qualidade de abrangência mundial, como ISO, o IEEE (www.ieee.org) e Mitre (www.mitre.org).
Por outro lado, mais de 65% do custo total de propriedade de uma aplicação é gasto na etapa de manutenção do sistema, ou seja, depois que o software já está construído. Isso quer dizer que, se o desenvolvimento de um produto custa US$ 700.000, a manutenção levará ao menos US$ 1,3 milhão. Portanto, se um arquiteto de software pudesse reduzir esse custo em 15%, significaria uma economia de US$ 195.000. No entanto, é possível ter um produto de software econômico e fácil de manter; tudo tem a ver com a qualidade. Vale a pena analisar o negócio da qualidade de software e qual é o papel que a arquitetura desempenha nesse processo.
O papel do arquiteto
Muitas vezes, ao querer otimizar uma aplicação para que alcance muitos desses atributos de qualidade ao mesmo tempo, o custo dispara e, em muitos casos, o faz de forma exponencial. Pode-se dizer que, para que uma aplicação funcione corretamente, não só precisa cumprir a funcionalidade para a qual foi projetada, como também precisa fazê-lo de forma ágil, segura e com baixos custos de manutenção.
Analisemos o caso do Twitter. Por que ele é tão simples? Principalmente porque é usável (nesse caso amigável e simples) e tem um curto tempo de resposta (performance) em geral, o que nos leva a pensar que há coisas que ficam de fora. O que acontece com a disponibilidade? O Twitter funciona 24 horas nos sete dias da semana? A resposta é não. Quando queremos fazer algo que põe em risco a performance do Twitter, aparece uma tela com uma mensagem que nos explica que Twitter is over capacity (o Twitter ultrapassou sua capacidade), o que indica que o site não caiu, mas, naquele momento, não é possível operar. Ainda assim, não há dúvidas de que, quando funciona bem, é rápido e usável. Agora, o que aconteceria se o Twitter permitisse 50.000 caracteres em vez de 140? Que impacto você acha que isso teria na performance? Na disponibilidade? E na facilidade de uso? Por trás dos atributos de qualidade de uma aplicação há um responsável por eles, que equilibra as equações: o arquiteto. Para visualizá-lo, pode-se pensar no personagem do filme Matrix, aquele senhor de barba que, em uma sala cheia de telas, dizia a Neo (o protagonista) que ele era o responsável por manter o equilíbrio de todas as equações para que a matrix funcionasse. Esse arquiteto era o projetista da matrix, a pessoa por trás do sistema. Um arquiteto de software deve não só lidar com a aplicação em si, mas também ser capaz de projetar e construir com as restrições intrínsecas do negócio (dinheiro, equipe atual, time disponível, tecnologia, entre outros). É o responsável pela plataforma, tecnologia e arquitetura definida, de tal forma que ela escale e possa enfrentar os desafios futuros do negócio.
A raiz de muitos fracassos em projetos de software costuma estar em uma arquitetura deficiente. Os números falam por si sós: 70% das aplicações têm problemas de disponibilidade ou performance. O arquiteto tem que lidar com todos esses fatores e, além disso, deve saber explicá-los. Para isso, existem métodos formais de avaliação de arquitetura e grupos de trabalho onde aprender e se formar.
Tudo mais simples
Para levar adiante a tarefa de definição e manutenção de uma arquitetura de software, existem métodos formais de avaliação de arquiteturas. Embora a maioria dos métodos trabalhe sobre uma definição e sobre os requisitos, existem formas inovadoras de trabalhar sobre aplicações sem documentação (ou com escassa documentação) e inclusive fazê-lo sobre a própria aplicação em produção.
Tudo fica mais simples quando se torna natural identificar o que há por trás das aplicações com qualidade deficiente e daquelas com muita funcionalidade e pouca performance ou pouca segurança, que são muito custosas de manter. Por trás, estará o papel do arquiteto de software e da arquitetura de software como prática nessa empresa. A pergunta, então, deveria ser: há um arquiteto de software nessa companhia? Ele tem os conhecimentos necessários? Suas definições são respeitadas e seguidas ao longo do ciclo de vida do produto? Há um processo de arquitetura?
Embora provavelmente as respostas a muitas dessas perguntas sejam negativas, nunca é tarde para começar a trabalhar sobre a arquitetura de software e cuidar dos atributos de qualidade mais importantes, para que a aplicação cumpra a funcionalidade para a qual foi projetada.
