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.
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 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.
