Em todo este livro, destaco como produto da prática de arquitetura de software todas as decisões de design determinantes para o atendimento dos objetivos de negócio, respeito as restrições e atingimento de atributos de qualidade. Estas decisões de design, então ditas arquiteturais, ficam expressas no conjunto de componentes que constituem sistemas de software, suas responsabilidades e interações, bem como a estratégia (padrão coerente para tomada de decisões) que governará a evolução.
Considerações sobre Atributos de Qualidade e Restrições
Atributos de qualidade e restrições são os fundamentos para as tomadas de decisão arquitetônicas. Os atributos de qualidade são aprimorados ou danificados por essas decisões, enquanto as restrições incluem ou excluem diretamente partes da arquitetura (por exemplo, os componentes lógicos ou tecnologias).
Uma lista, não exaustiva, porém comum de atributos de qualidade incluem:
- Performance, indicando quanto rapidamente um sistema consegue executar uma determinada atividade;
- Escalabilidade, determinando a capacidade de um sistema de lidar com mais usuários, requisições, dados, mensagens, etc.
- Disponibilidade, com relação ao percentual de requisições que um sistema consegue responder dentro de uma expectativa de performance.
- Segurança, talvez o mais essencial dos atributos, indicando a capacidade de um sistema de preservar confidencialidade, integridade e disponibilidade frente a tentativas de desestabilizar o sistema.
- Flexibilidade, indicando suporte a ampliação de escopo de features ou a capacidade de um sistema de permitir que uma mesma ação seja executada de mais de uma forma
- Extensibilidade, permitindo a adição de features ou dados além dos planejados e implementados “no código”
- Manutenabilidade, com vistas a estabilizar custos para manter
- Evolvability, combinando a capacidade de um software evoluir, tanto em tecnologia quanto em features, sem sacrificar a manutenabilidade.
- i18n e l10n
Uma lista não exaustiva de restrições, inclui:
- Restrições de prazo e orçamento;
- Listas de tecnologias aprovadas;
- Necessidade de preservar retrocompatibilidade e gestão de legado;
- Plataformas operacionais que precisam ser suportadas;
- Relacionamento com vendors
- Tamanho e skills do time
Arquitetura de software como descoberta
A prática da arquitetura de software é, então, também, uma prática de descoberta. Primeiro, do que se entende dos objetivos de negócio, restrições e atributos de qualidade. Estas informações, aliás, quase nunca evidentes e frequentemente incompletas inicialmente. Depois, de alternativas propositivas de design compatíveis.
De muitas formas, o método de trabalho para a prática de arquitetura de software assemelha-se a resolução de problemas Sudoku. Afinal, em ambos, no Sudoku e na prática de arquitetura, tudo começa com um conjunto incompleto de informações e a solução é encontrada interativamente, a partir do preenchimento de espaços em branco de acordo com aquilo que se sabe para, etapa por etapa, substituir possibilidades por certezas.
As distinções entre Sudoku e arquitetura, entretanto, começam no entendimento de que enquanto para problemas Sudoku há uma única solução possível. Enquanto isso, problemas arquiteturais, geralmente existem múltiplas alternativas viáveis.
Arquitetura de software como resolução de tensões
Entre as informações disponíveis inicialmente, geralmente está uma visão superficial dos objetivos de negócio desejados, imposições de orçamento e normativas (restrições) e sinalizações sobre atributos de qualidade relacionados. Assim como em problemas Sudoku, a partir dessas informações, faz-se inferências para clarificação contextual a partir destes elementos tensores.
De muitas formas, a prática de arquitetura de software equilibra forças e alivia tensões entre objetivos de negócio, restrições e atributos de qualidade.
Por exemplo, em um sistema que suporta prestadores de serviço, pode ser um objetivo de negócio a capacidade de processar recebimentos. Daí, infere-se a necessidade da observação de segurança como atributo de qualidade, que implica na restrição de apartar redes que hospedam serviços internos (controlados) daquelas que hospedam serviços externos através de uma DMZ.
Seguindo o exemplo anterior, o entendimento de segurança como atributo de qualidade, eventualmente implicará, também no atendimento de confidencialidade, integridade e disponibilidade. Na sequência, restrições associadas, como, por exemplo, adoção de tecnologias certificadas são inferidas e, dado o custo, obrigam a ampliação e descoberta de novos objetivos de negócio que “façam a conta fechar”.
Eventualmente, novas restrições externas podem ser impostas (como novas instruções normativas), tensionando o contexto, impactando nos objetivos de negócio e em atributos de qualidade. Nesses casos, novas inferências precisam ser feitas de forma a equilibrar as tensões e dissolver conflitos.
Arquitetura de software como resolução de trade-offs
Não raro, medidas para melhorar dois ou mais atributos de qualidade, respeitar restrições ou atender objetivos de negócio são conflitantes. Ou seja, não podem ser adotadas juntas. Há também cenários onde ações que favorecem a alguns dos objetivos arquiteturais prejudicam outros. Nessas horas, ocorre um trade-off.
É papel do arquiteto de software orquestrar interações entre todos os stakeholders para eliminar trade-offs.
Arquitetura de software como enabler de transformação
Dos objetivos de negócio infere-se tanto o modelo de negócios como do modelo operacional que será suportado pelo software que se pretende desenvolver e manter.
O modelo de negócios compreende respostas para as perguntas “Quais são os produtos ou serviços oferecidos? Para quem?” e “Quanto é cobrado pelos benefícios gerados? De quem? Como?”. Já o modelo operacional implica em respostas para “Como a empresa gera seus produtos e serviços? Em que escala? Em que escopo? Como aprende?”
As respostas de todas as perguntas indicadas tensionam o contexto, demandando a introdução ou revisão de novas restrições e atributos de qualidade.
Arquitetura de software como design (finalmente!)
A partir de um conjunto qualificado e distensionado de objetivos de negócios, restrições e atributos de qualidade, emergem condições favoráveis para proposições de design. Ou seja, organização de componentes – com responsabilidades e regras explícitas de interação.
Eventualmente, proposições de design impactam no reconhecimento de novas restrições e na revisão dos atributos de qualidade para novo distensionamento.
As diversas proposições de design devem ser avaliadas e escolhidas obedecendo algum critério de eficiência – geralmente, menor custo.
Eventualmente, uma das proposições é selecionada e fundamenta a implementação.
Arquitetura de software como enabler de melhoria contínua
Uma vez selecionada uma proposição de design, seguem atividades de implantação, operação e evolução, governadas por um conjunto de fitness functions que expressam, principalmente, objetivos de negócio e atributos de qualidade.
Em algum momento, a medida que ocorrem mudanças significativas de escala ou escopo, anomalias ocorrem e, na ocorrência, implicam em retomada de descobertas de objetivos de negócio, restrições e atributos de qualidade.