O valor de um software é determinado pela sua capacidade de atender, hoje e no futuro, as demandas do negócio, respeitando restrições, demonstrando atributos de qualidade, com custo e risco razoáveis. Infelizmente, manter o valor de um software não é tarefa fácil em empresas grandes.

Accelerate: Building and Scaling High Performing Technology Organizations As quatro métricas indicadas no texto são defendidas e detalhadas nesse excelente livro. Leitura obrigatória para pessoas realmente interessadas em cultura lean e DevOps. Acessar livro

Empresas grandes são, frequentemente, vítimas de desaceleração. O antídoto para esse problema, acredito, passa pela adoção de arquiteturas modulares.

Large-Scale C++ Software Design Não se deixe assustar pelo “C++” no título desse livro. Trata-se, enfaticamente, da primeira e, provavelmente, uma das mais influentes obras sobre arquitetura modular disponível. Acessar livro

O design arquitetural modular habilita tanto times eficazes e eficientes quanto software que preserva valor ao longo do tempo. Os princípios, discutidos nesse livro, apresentam uma abordagem pragmática para lidar com os desafios de reuso, distribuição e evolução.

Introducing Large-scale C++, volume I: Process and Architecture Excelente palestra de John Lakos, sobre arquitetura modular. Uma “introdução” as ideias que compartilhou em sua obra. Acessar vídeo

A demanda por flexibilidade, sem complexidades

Making everything easy to change makes the system very complex. Ralph Johnson

Em nossa realidade, onde negócios e organizações mudam o tempo todo, software precisa ser fácil de modificar. Afinal, software não adaptado pode representar desvantagem competitiva. Sob esta perspectiva, a arquitetura precisa ser flexível.

A prática da boa arquitetura de software busca determinar os “pontos” de um sistema de software que demandam flexibilidade, restringindo-a a esses pontos, mitigando complexidade.

Complexidade, para ser evitada, precisa ser combatida

Ao longo de décadas, Meir Lehman e László Bélády formularam, propuseram e aprimoraram diversas “leis” que, alegadamente, governam a evolução de sistemas de software. Essas leis ficaram conhecidas como “Leis de Lehman”.

As “Leis de Lehman” descrevem e ajudam a entender o sensível equilíbrio entre as motivações para a evolução de um software, por adaptações, e as causas para o aumento da complexidade (em consequência, do lead time para atender demandas do negócio) ao longo do tempo.

As Leis de Lehman Acessar episódio

As duas primeiras “leis” formuladas por eles, em 1974, foram a lei da “mudança contínua” e a lei da “complexidade crescente”. A primeira diz que, ao longo do tempo, um sistema de software precisa ser continuamente adaptado, recebendo novas “adaptações”, para se manter relevante e satisfatório. A segunda aponta que, enquanto essas “adaptações” são feitas, o software se torna mais complexo, exceto quando existam esforços explicitamente direcionados para mitigar essa complexidade.

Complexidade gera sobrecarga cognitiva

Como já sabemos, a complexidade do software tende a aumentar ao longo do tempo, aumentando, também o esforço cognitivo demandado para sua manutenção.

Cargas cognitivas mais altas demandam times maiores e, com isso, provocam a diluição do conhecimento e a difusão das responsabilidades.

Como forma de mitigar os impactos decorrentes do aumento da complexidade, times de desenvolvimento precisam:

• garantir ênfase operacional a carga cognitiva intrínseca, relacionada a aspectos fundamentais do trabalho para resolução de problemas;
• automatizar trabalho fonte de carga cognitiva estranha, relacionadas ao ambiente de execução das tarefas, como processos de testes, build e release;
• dedicar tempo suficiente para carga cognitiva pertinente, relacionada ao entendimento do domínio dos problemas e formulação dos planos para abordagem.

Modularização mitiga a complexidade

A mitigação da complexidade de um software acontece pela sua divisão em partes menores, conhecidas como módulos.

Um módulo é um elemento na arquitetura que é projetado de tal forma que tenha forte interdependência interna (integração funcional completa) e dependências e interações externas fracas ou mínimas.

A possibilidade de substituir módulos inteiros por outros com interface compatível adiciona flexibilidade as arquiteturas. Por outro lado, quando coesos módulos são “rígidos” internamente, mitigando complexidade.

Os “pontos de contato” entre os diversos módulos de um sistema são, também, os “pontos demandantes de flexibilidade”.

Modularização autoriza o reuso

Os módulos de um software são “unidades de reuso” e, por isso, também devem ser as “unidades de distribuição”.

O bom design de software estimula o desenvolvimento de elementos, de forma que eles possam ser reutilizados para fins diferentes daqueles que motivaram sua criação – seja pela equipe responsável ou por outras equipes da organização. Para isso, esses componentes devem ser agrupados e distribuídos em unidades físicas coesas.

A possiblidade de reuso está diretamente relacionada as dependências. Módulos com maior acoplamento aferente (incoming dependencies) apresentam custo maior para modificação. Módulos com menor acoplamento eferente (outcoming depedencies) apresentam maior custo de reuso.

A necessidade da distribuição relaciona a um módulo algum tipo de gestão, incluindo políticas de versionamento.

Módulos são unidades físicas

A arquitetura de software envolve dois tipos de design: lógico e físico.

O design lógico contempla o projeto da gestão do estado e comportamento. O design físico indica como tais unidades serão combinadas em artefatos passíveis de distribuição.

Os módulos de um sistema são determinados no design físico (e não no lógico).

A manifestação física dos módulos varia conforme a tecnologia analisada. Em Java, módulos são arquivos JAR. Em .NET, módulos são arquivos DLL. No “mundo dos grupos contêneires”, cada contêiner é um módulo em potencial.

Java Application Architecture: Modularity Patterns with Examples Using OSGi Este livro é, talvez, a principal referência disponível para interessados em arquitetura de software sob a perspectiva física (modular). Mesmo com exemplos em Java usando OSGi, apresenta padrões e conceitos aplicáveis em qualquer stack tecnológico. Acessar livro

Módulos influenciam a estrutura dos times

Módulos, como elementos do design físico, com gestão para distribuição, são entregáveis de times de engenharia.

Idealmente, um único time de engenharia pode ter ownership de diversos módulos. Entretanto, cada módulo deve ser “propriedade” de apenas um time. Logo, a modularização de um sistema, no design físico da arquitetura, acaba determinando a estrutura dos times de desenvolvimento, confirmando a lei de Conway.

A lei de Conway Interessado em saber mais sobre a lei de Conway? Veja essa edição do Tecn’n’biz, disponível em áudio e vídeo. Acessar episódio

Modularização é um fenômeno sistêmico

Entender um sistema – seja um software inteiro, apenas um módulo ou uma organização de engenharia, por exemplo –  implica, primeiro, na compreensão da relação entre seus comportamentos e sua estrutura. Este é o fundamento da teoria dos sistemas.

Thinking in Systems: A Primer Em um mundo com mudanças acontecendo de forma cada vez mais acelerada, pensamento sistêmico é capacidade fundamental.  Thinking in Systems, de Donella Meadows, é uma das melhores referências no assunto. Acessar livro

No contexto de sistemas de software, devido a lei de Conway, o entendimento estrutural deve incluir tanto o software quanto os times responsáveis por ele. Ela ensina que times com estruturas ineficientes não produzem software de valor. Analogamente, software mal estruturado desautoriza times eficientes.

O arquiteto de software busca melhorar os resultados de um sistema, sobretudo por meio de ajustes estruturais, não ambientais.

It is almost irresistible to blame something or someone else, to shift responsibility away from ourselves, and to look for the control knob, the product, the pill, the technical fix that will make a problem go way. Donella Meadows

A estrutura de uma organização de engenharia determina o valor do software que ela produz. Times monolíticos, por exemplo, não produzem sistemas baseados em microsserviços. São necessárias organizações modulares para produzir sistemas de software modulares.

Para pensar…