A arquitetura de software é difícil porque mistura codificação, matemática e sistemas de negócios. Devido a surpresas, as arquiteturas tendem a se tornar irrelevantes com o tempo, disse Barry O’Reilly no Goto Copenhagen. Ele apresentou a teoria da residualidade, onde sugeriu estressar arquiteturas ingênuas para revelar “atratores” ocultos em sistemas de negócios complexos. Isso permite que os designs sobrevivam melhor às mudanças e incertezas.
A arquitetura de software é difícil porque requer um amplo conjunto de habilidades, disse O’Reilly. Precisamos dominar o mundo do código, matemática e lógica, e o mundo dos sistemas humanos e de negócios, e entender como esses dois se relacionam e afetam um ao outro.
Na universidade, eles só nos ensinam a tecnologia. Quando começamos a projetar sistemas, percebemos que a complexidade do ambiente de negócios constantemente nos surpreende, tornando nossas arquiteturas irrelevantes, disse O’Reilly. Fazer algo tão estático e rígido quanto uma arquitetura de software sobreviver em um mundo fluido que está sempre mudando não é uma tarefa fácil, acrescentou.
A residualidade assume que uma simulação aleatória de estresse em uma arquitetura ingênua produzirá uma arquitetura melhor do que os métodos tradicionais em torno da engenharia de requisitos, gestão de riscos ou reagir à mudança à medida que ela acontece, explicou O’Reilly:
“Isso começou como uma observação curiosa, e nos últimos 10 anos, tive que construir explicações teóricas e experimentos para mostrar que isso realmente é o caso. Armados com esse conhecimento, podemos pensar de forma diferente sobre a arquitetura de software e construir novas ferramentas.”
Como estudantes da ciência ocidental, nosso primeiro recurso é reduzir qualquer sistema complexo a suas partes componentes e estudar essas partes em detalhes. Este é o padrão para engenheiros de software, disse O’Reilly. Em sistemas complexos, o número de elementos e potenciais interações e estados torna essa análise detalhada impossível. Gerações anteriores de arquitetos tentaram reduzir a complexidade do ambiente de negócios à lógica, ou a estruturas, ou ao processo de desenvolvimento.
Um dos aspectos-chave dos sistemas complexos é que eles nunca visitam todos os estados possíveis que a combinação de seus elementos permite. Em vez disso, as interações dos elementos restringem o sistema a um número muito pequeno de estados potenciais, que chamamos de “atratores”, disse O’Reilly. Portanto, um sistema de negócios complexo não é modelado como um número de elementos de interação e suas relações, mas sim como um número de atratores, explicou:
“Quando construímos uma arquitetura, são esses atratores que a arquitetura deve sobreviver. Os atratores, portanto, fornecem uma maneira muito mais simples, fácil e pragmática de interagir com a complexidade do ambiente.”
O problema é que não sabemos quais são os atratores, mas ao simular aleatoriamente estresse, podemos descobrir muitos deles, disse O’Reilly. Se você pensar nas principais falhas arquitetônicas que já viu, verá que elas falham principalmente porque perderam atratores, mencionou.
A teoria da residualidade é um processo muito simples. Às vezes, as pessoas se sentem desmotivadas porque o trabalho teórico necessário para provar que a residualidade funciona é muito pesado, mas aplicá-la é fácil, explicou O’Reilly:
“Começamos com uma sugestão, uma arquitetura ingênua que resolve o problema funcional. A partir daí, estressamos a arquitetura com potenciais mudanças no ambiente. Esses estressores nos permitem descobrir os atratores, muitas vezes através de conversas com especialistas no domínio. Para cada atrator, identificamos o resíduo, o que resta da nossa arquitetura nesse atrator, e então mudamos a arquitetura ingênua para que ela sobreviva melhor.
Fazemos isso muitas vezes e, no final, integramos todos esses resíduos aumentados em uma arquitetura coerente. Podemos então testar isso para mostrar que sobrevive a formas desconhecidas de estresse melhor do que nossa arquitetura ingênua.”
Em ambientes de negócios complexos com incerteza, a residualidade torna possível criar arquiteturas rapidamente em vez de correr atrás de partes interessadas exigindo requisitos específicos ou respostas a perguntas que são desconhecidas pelo próprio negócio, disse O’Reilly. Isso retira os arquitetos técnicos dos detalhes e os ensina a se envolver produtivamente com um ambiente de negócios sem as linhas e caixas da arquitetura empresarial tradicional, concluiu.
InfoQ entrevistou Barry O’Reilly sobre a residualidade.
InfoQ: Como podemos provar que a arquitetura residual que criamos é uma melhoria em relação à arquitetura ingênua?
Barry O’Reilly: Um teste simples é usar um segundo conjunto de estressores para verificar se nossa arquitetura residual sobrevive a mais eventos desconhecidos do que nossa arquitetura ingênua. Você pode facilmente ver as semelhanças entre isso e os conjuntos de treinamento/teste de ML. A teoria da residualidade, em última análise, afirma que as arquiteturas devem ser treinadas, não projetadas.
InfoQ: Quais benefícios você viu da análise residual?
O’Reilly: Arquitetos seniores relatam que isso fornece uma justificativa teórica para práticas que muitos já haviam descoberto e um vocabulário compartilhado para as equipes falarem sobre arquitetura. Em última análise, isso torna a arquitetura mais explícita, melhor definida e mais fácil de ensinar. O resultado são arquiteturas em que podemos acreditar e uma tomada de decisão que é rastreável.
Tem seus desafios também. Um pequeno número de desenvolvedores acha difícil a transição do mundo linear, lógico e matemático para as técnicas laterais e imaginativas. A residualidade é um assunto tão grande quanto OOP e requer a mesma quantidade de esforço para aprender.