Tradeoff Analysis

Olá pessoal!

O tema deste post é bastante recorrente no nosso dia-a-dia. Prazos curtos, recursos e custos limitados, expectativa por qualidade do resultado final e requisitos bastante ousados. A regra para esta situação é simples: you can’t have it all (você não pode ter tudo). Isso é o que diz Mark Richards no livro 97 Things Every Software Architect Should Know, já citado em outros artigos deste blog anteriormente. E para ilustrar este cenário, Mark conta a história do navio Vasa, que também pode ser encontrada no livro Software Architecture in Practice – Second Edition, de Len Bass, Paul Clements e Rick Kazman, onde são mostradas opções que podem evitar o problema que veremos a seguir.

A história se passa em 1620, quando Suécia e Polônia estavam em guerra. Objetivando a vitória, o rei da Suécia encomendou um navio fora dos padrões da época, o Vasa. Capacidade para trezentos soldados e sessenta e quatro armas pesadas distribuídas em dois decks eram os requisitos do navio. Tal capacidade de transporte de pessoas e capacidade de fogo era algo completamente sem precedentes. Para atender tal demanda um projetista de navios renomado foi chamado: Henrik Hybertsson. Apesar da sua reputação impecável e vasta experiência no ramo, este era um projeto extremamente desafiador para Henrik, pois, ele nunca tinha projetado um navio deste porte antes. Sua especialidade era navios de guerra comuns, de apenas um deck de armamento. Para piorar o cenário, além dos requisitos de performance, segurança, confiabilidade e funcionalidade, Henrik tinha que lidar com restrições de custo e tempo. Oito anos após a encomenda o Vasa finalmente foi entregue de acordo com as especificações, estando pronto para sua primeira viagem. Após navegar por trinta metros o Vasa disparou seus canhões em saudação e afundou logo em seguida. Investigações concluíram que o navio havia sido bem construído, porém, não havia sido bem projetado.

A conclusão desta história no livro Software Architecture in Practice – Second Edition é que apesar de passados quase quatrocentos anos do corrido, o que é denominado “Architecture Business Cycle” é bem ilustrado: os objetivos da organização (do Rei no contexto da guerra) delineiam os requisitos (poder de fogo e transporte de soldados), que delineiam a arquitetura (dois decks de armamento, setenta metros de comprimento) que por sua vez delineia um sistema (o navio que naufragou). No livro são então apresentadas três opções que devem ser consideradas quando falamos de projetos de arquitetura de sistemas reais:

• A verificação de estudos de caso de arquiteturas bem sucedidas que atendam a requisitos semelhantes;
• A utilização de métodos para avaliar uma arquitetura antes que qualquer sistema tenha sido construído a partir dela, de forma a mitigar os riscos associados aos requisitos sem precedentes (veremos mais detalhes a seguir);
• A utilização de técnicas incrementais para o estabelecimento da arquitetura, de forma a descobrir problemas de design antes que seja muito tarde.

Para Mark, no livro 97 Things Every Software Architect Should Know, tentar cumprir todo e qualquer requisito pode levar a criação de uma arquitetura que essencialmente não faça nada de forma satisfatória. Foi o caso do Vasa, que acabou ficando desproporcional para atender as capacidades de armamento e transporte requeridas. Mark cita ainda exemplos de requisitos normalmente mutuamente exclusivos: performance versus alta interoperabilidade, reuso e diversas camadas de uma arquitetura SOA. Mark recomenda então a utilização de técnicas para o que é conhecido como  “Tradeoff Analysis”.

Tradeoff é uma situação que envolve perda de qualidade ou aspecto em algo em prol do ganho de outra qualidade ou aspecto. Considere o seguinte exemplo, ao guardar dados em memória podemos ter ganhos de performance associados ao acesso rápido, porém, teremos maior consumo de memória pela aplicação e possibilidade de trabalhar com dados desatualizados, já que a fonte original não estaria sendo consultada diretamente. O objetivo de uma análise de tradeoffs é ajudar na escolha de uma arquitetura adequada para um sistema pela descoberta de tradeoffs e pontos sensíveis. Duas técnicas são citadas para este objetivo: ATAM (Architectural Tradeoff Analysis Method) e CBAM (Cost Benefit Analysis Method). Ambas estão descritas no livro Software Architecture in Practice – Second Edition e também no site do SEI (Software Engineering Institute).