O que se pede e o que se espera
Os requisitos funcionais escrevem-se sozinhos: o sistema deve registar encomendas, emitir faturas, enviar avisos. Os outros, os que decidem de facto a arquitetura, quase nunca se escrevem: quanto tempo pode estar em baixo, quantos dados pode perder, quanto pode custar por mês, quantos utilizadores tem de aguentar no dia de maior carga.
Ninguém os pede, mas todos os dão como garantidos. E quando o sistema não os cumpre, o problema não é técnico: é que nunca foram acordados.
Os atributos que decidem o desenho
- Disponibilidade. Que percentagem do tempo deve funcionar e em que horário importa.
- Recuperação. Quanto pode demorar a voltar depois de uma falha (objetivo de tempo de recuperação) e quantos dados pode perder (objetivo de ponto de recuperação).
- Desempenho. Tempo de resposta aceitável e carga máxima esperada.
- Segurança. Que dados trata, quem pode aceder e que regulamentação se aplica.
- Custo. Quanto pode custar operá-lo, e como esse custo deve crescer com a utilização.
- Operabilidade. Quem o opera, com que conhecimentos e com que ferramentas.
Tudo tem um preço
Nenhum desenho maximiza tudo ao mesmo tempo. Mais disponibilidade significa mais redundância, e mais redundância significa mais custo. Recuperar em minutos exige réplicas que custam dinheiro todos os meses. Por isso, os atributos de qualidade não se pedem «ao máximo»: negociam-se e escrevem-se com um número.
«Alta disponibilidade» não é um requisito. «Disponível 99,9 % do tempo em horário laboral, com recuperação em menos de uma hora e perda máxima de quinze minutos de dados» é, e permite desenhar, estimar e verificar.
Como torná-los explícitos
- Perguntar pelas consequências, não pelos números: o que acontece se isto estiver em baixo uma hora numa segunda-feira? A resposta dá o número.
- Escrevê-los numa tabela curta, com um valor por atributo e quem o acordou.
- Ligá-los ao custo: cada atributo com o seu impacto estimado na fatura mensal.
- Revê-los quando o negócio mudar, não quando o sistema falhar.
Com os requisitos escritos, cada decisão de arquitetura tem com que se medir. Sem eles, qualquer desenho parece razoável.
Como o aplicamos: Arquitetura Cloud.