1 of 29

Gabriel S. Kohlrausch

Consultor/Technical Advisor at EximiaCo

gabriel@eximia.co

Arquiteturas que

Evoluem

2 of 29

PÁGINA ⠀2⠀

SOFTWARE MUDA

‘‘Há muito tempo acreditamos que, quando a taxa de mudança dentro de uma instituição se torna mais lenta do que a taxa de mudança externa, o fim está à vista. A única questão é quando.’’

Jack Welch

3 of 29

PÁGINA ⠀3⠀

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.

LEIS DE LEHMAN

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.

As duas leis, deliciosamente evidentes e conflitantes, levam a alguns desdobramentos preocupantes:

-Projetos de software bem sucedidos estão “condenados” a demandarem trabalho para mitigar a complexidade.

-Times extremamente eficazes, mas exclusivamente focados em atender as demandas de negócio se tornam, eventualmente, menos produtivos, deteriorando sua capacidade de fazer entregas e, consequentemente, sua eficácia.

-O esforço para combater a complexidade é imperativo para manter o software relevante no médio/longo prazo.

-Times de negócio que não se sensibilizam para a necessidade de reduzir a complexidade do software, priorizando somente inclusão de features, se condenam a ter suas demandas atendidas em prazos cada vez maiores.

4 of 29

PÁGINA ⠀4⠀

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.

LEIS DE LEHMAN

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.

As duas leis, deliciosamente evidentes e conflitantes, levam a alguns desdobramentos preocupantes:

-Projetos de software bem sucedidos estão “condenados” a demandarem trabalho para mitigar a complexidade.

-Times extremamente eficazes, mas exclusivamente focados em atender as demandas de negócio se tornam, eventualmente, menos produtivos, deteriorando sua capacidade de fazer entregas e, consequentemente, sua eficácia.

-O esforço para combater a complexidade é imperativo para manter o software relevante no médio/longo prazo.

-Times de negócio que não se sensibilizam para a necessidade de reduzir a complexidade do software, priorizando somente inclusão de features, se condenam a ter suas demandas atendidas em prazos cada vez maiores.

5 of 29

PÁGINA ⠀5⠀

Percebemos valor de um software através de suas funcionalidades e pela sua arquitetura.

QUAL O VALOR DE SOFTWARE ?

As funcionalidades de um software são expressas em dados e comportamentos. Trata-se da parte com utilidade mais percebida de um sistema. São as funcionalidades que suportam atividades dos usuários, de forma economicamente favorável (geralmente economizando tempo e dinheiro) e, por causa disso, muitas vezes, são entendidas como única manifestação de valor.

A arquitetura de um software trata de como ele está organizado, em termos de componentes e conexões, para suportar as funcionalidades. A arquitetura garante que o software continuará fazendo a coisa certa, do jeito certo, ao longo do tempo.

Um software terá mais valor quando conseguir suportar adequações de suas funcionalidades, ao longo do tempo, no ritmo necessário (por sinal, cada vez mais acelerado). Para isso, é de fundamental importância que possua uma arquitetura flexível que consiga acomodar essas adequações.

Arquiteturas mal estruturadas tornam mais custosas, ao longo do tempo, a realização das mudanças necessárias para ajustar as funcionalidades de um sistema. Isso faz com que embora elas não sejam diretamente percebidas por pessoas do negócio, tenham relevância também para elas.

6 of 29

PÁGINA ⠀6⠀

O ritmo das mudanças, tecnológicas e de negócios, está acelerado e está ficando cada vez mais acelerado. Aliás, essa é a característica que melhor justifica as atividades de arquitetura.

BOAS ARQUITETURAS SUPORTAM MUDANÇA

Boas arquiteturas sustentam sistemas que suportam melhor a mudança. Entretanto, tais arquiteturas não são fáceis, tampouco triviais. Elas demandam conhecimento especializado sob aspectos estruturantes que se afastam de aspectos menores de desenvolvimento do dia-a-dia. Por sua especificidade, demandam especialidade, logo, o envolvimento de especialistas.

Eventualmente, bons sistemas são desenvolvidos a partir das “cicatrizes” do time. Ou seja, utilizando arquiteturas de sistemas desenvolvidos com êxito no passado como referência para uma nova solução. Entretanto, isso não é indicativo de que conhecimentos relacionados a arquitetura sejam menos importantes, apenas indica que decisões arquiteturais podem, eventualmente, ser “requentadas” para resolver cenários com problemas de negócio, restrições ou atributos de qualidade similares.

Há também, sistemas que evoluem suas arquiteturas com base em modismos, influências de terceiros ou preferências difíceis de justificar. Nestes cenários, prejuízos acabam sendo percebidos mais tarde e por muito tempo. Geralmente, no longo prazo, tais soluções se convertem em “colchas de retalhos” com custo crescente de manutenção.

7 of 29

PÁGINA ⠀7⠀

ARQUITETURA DE SOFTWARE

COMPONENTES

RESPONSABILIDADES

RELACIONAMENTOS

+

ESTRATÉGIA

(Objetivos de negócio, restrições e atributos de qualidade)

BUSCANDO O MENOR RISCO/CUSTO

Arquitetura de software são as coisas importantes de um software. O que quer que isso seja.

Ralph Johnson

Embora não exista consenso absoluto sobre o conceito, alguns aspectos são amplamente aceitos. Qualquer discussão madura sobre a arquitetura de um software aborda, de maneira mais ou menos qualificada, seus componentes, a responsabilidade destes e a forma como eles se relacionam. Aliás, isto está alinhado com a definição proposta pelo IEEE, que é uma das mais mencionadas.

Estratégia é um padrão coerente para tomada de decisões. Ou seja, quando todas as pessoas de um grupo tomam decisões seguindo um mesmo padrão coerente, obedecendo um conjunto estável de critérios, diz-se que estão alinhados a uma mesma estratégia – mesmo quando, eventualmente, as decisões em si sejam diferentes.

Na prática, isso significa, por exemplo, que qual framework utilizar no frontend, por exemplo, é menos relevante, sob a perspectiva da arquitetura, que os critérios que foram utilizados para adotar tal tecnologia.

8 of 29

PERFORMANCE

PÁGINA ⠀8⠀

TRADE-OFFS

SECURITY

AVAILABILITY

DATA

SCALABILITY

FUNCIONALIDADES

TEMPO

9 of 29

PERFORMANCE

PÁGINA ⠀9⠀

EVOLVABILITY COMO ATRIBUTO DE QUALIDADE

SECURITY

AVAILABILITY

DATA

SCALABILITY

FUNCIONALIDADES

TEMPO

EVOLVABILITY

10 of 29

PÁGINA ⠀10⠀

Atributo de qualidade relacionado à capacidade de um sistema “evoluir”, tanto para atender demandas de negócio como para “acomodar” novidades tecnológicas, sem comprometer objetivos do negócio, desrespeitar restrições ou romper os demais atributos, minimizando custo ou risco.

EVOLVABILITY

11 of 29

PÁGINA ⠀11⠀

Capacidade de suportar mudanças incrementais, preservando a eficiência no decorrer do tempo, sendo guiada por fitness functions, que comprovam continuamente adequação a parâmetros de qualidade bem-definidos em múltiplas dimensões.

ARQUITETURA EVOLUCIONÁRIA

12 of 29

PÁGINA ⠀12⠀

O “represamento” das iniciativas para modernização tecnológica é uma das maiores causas para a “morte” dos sistemas de software. Mesmo quando tecnologias não agregam “algo novo”, o afastamento da trajetória evolutiva das ferramentas, técnicas e práticas por um tempo prolongado aumenta de maneira exponencial o custo e risco para a mudança, apesar dos custos de oportunidade.

MUDANÇAS INCREMENTAIS

13 of 29

PÁGINA ⠀13⠀

MUDANÇAS TECNOLÓGICAS

Não conseguimos predizer quando mudanças impactantes do contexto de desenvolvimento irão ocorrer. Nem mesmo conseguimos antecipar quais serão “persistentes” (se é que essa palavra é aplicável), entretanto, sabemos que mudanças acontecem e o ritmo parece ser cada vez mais acelerado.

O conjunto de tecnologias, técnicas, padrões e boas práticas para desenvolver software são dinâmicas e instáveis. Essa instabilidade, aliás, é um dos principais desafios para manter e evoluir sistemas.

A emergência de práticas como a utilização de contêineres, aceleradas por tecnologias como Docker, por exemplo, impactam a indústria de forma definitiva e, para os menos “antenados”, parece surgir de uma hora para outra.

Linguagens novas de programação, mais expressivas (pelo menos para alguns domínios) também surgem em ritmo cada vez mais acelerado. Recentemente, mesmo as linguagens consolidadas também passaram a receber atualizações mais frequentes. Em consequência disso, bases de código gigantes que geram sistemas em produção, parecem cada vez mais “legadas” em prazos cada vez mais curtos.

Frameworks Javascript parecem crescer em popularidade e se tornarem obsoletas em ciclos, muitas vezes, menores do que os necessários para o desenvolvimentos de alguns grandes sistemas. Em poucos anos, vimos o declínio de jQuery; a ascensão e a “morte” de AngularJS; a “provocação” de Backbone e Mustache; o progresso com Angular, React e Vue; propostas ousadas multiplataforma como Flutter e Electron; etc. É quase impossível dizer qual será a tecnologia dominante para elaboração de frontends de aqui dois anos.

14 of 29

PÁGINA ⠀14⠀

SOFTWARE LEGADO

‘‘Um sistema se torna legado quando nossa capacidade de pagar dívidas técnicas é menor que a necessidade de contrair novas.’’

Fernando�Paiva

15 of 29

PÁGINA ⠀15⠀

MUDANÇAS INCREMENTAIS

16 of 29

PÁGINA ⠀16⠀

Architecture fitness functions são um tipo de função objetivo que é usada para resumir o quão perto uma determinada solução de arquitetura de software está de atingir os objetivos definidos.

GUIADA POR FITNESS FUNCTIONS

Quando falamos em governança, devemos encontrar meios objetivos – fórmulas – que se observadas regularmente, demonstram a “aproximação” da solução arquitetural de um “ideal” – por isso, são identificadas como architectural fitness functions.

Trata-se de um conceito derivado das fitness functions, comuns em algoritmos genéticos.

Exemplo tamanho da rota para ML de calculo de rota em algoritmo genetico

Architectural fitness functions podem ser holísticas – apuradas com base no software como um todo – ou isoladas, geradas automaticamente (o ideal) ou através de processos manuais, disparadas pelo processo automaticamente ou acionadas explicitamente (como “desempenho” em testes de carga), estáticas (mensuráveis a partir do código) ou dinâmicas (demandando software em execução)

17 of 29

PÁGINA ⠀17⠀

FITNESS FUNCTION DEPENDENCY CYCLES

18 of 29

DETERMINANDO O VOLUME

“IDEAL” DE ABSTRAÇÕES

PÁGINA ⠀18⠀

COMPONENTES MUITO ABSTRATOS E INSTÁVEIS

COMPONENTES CONCRETOS E ESTÁVEIS

Domain.Core�A = 0.13�I = 0.48

Projeto: Application.Schedule�A = 0.08�I = 0.93

Project: Application.Authentication�A = 0.5�I = 0.84

https://dateo-software.de/blog/get-started-with-ndepend

19 of 29

PÁGINA ⠀19⠀

FITNESS FUNCTION PARA ACOPLAMENTO

20 of 29

PERFORMANCE

PÁGINA ⠀20⠀

MÚLTIPLAS DIMENSÕES

SECURITY

AVAILABILITY

DATA

SCALABILITY

FUNCIONALIDADES

TEMPO

FITNESS FUNCTIONS

Load Testing

21 of 29

LOAD TESTING COMO FITNESS FUNCTIONS

PÁGINA ⠀21⠀

22 of 29

PÁGINA ⠀22⠀

O estabelecimento de governança arquitetural passa pela definição de guidelines e guard rails que determinam um “jeito” de fazer as coisas e limites claros dentro dos quais há autonomia de atuação.

EVOLVABILITY DEMANDA “GOVERNANÇA ARQUITETURAL”

23 of 29

PÁGINA ⠀23⠀

GUIDELINES E GUARDRAILS

https://github.com/TNG/ArchUnitNET

24 of 29

PÁGINA ⠀24⠀

GUIDELINES E GUARDRAILS

https://github.blog/2016-02-03-scientist/

https://github.com/github/scientist

https://github.com/MisterSpex/misterspex-scientist

25 of 29

PÁGINA ⠀25⠀

GUIDELINES E GUARDRAILS

https://github.blog/2016-02-03-scientist/

https://github.com/github/scientist

https://github.com/MisterSpex/misterspex-scientist

26 of 29

PÁGINA ⠀26⠀

‘‘Entretanto, não ignoramos o fato que toda escolha implica em uma renúncia. Sempre haverão trade-offs. Nada é bom para tudo!’’

Elemar Jr.

TRADE-OFFS

27 of 29

O QUE FAZER AMANHÃ?

PÁGINA ⠀27⠀

OBJETIVOS DE NEGÓCIO, RESTRIÇÕES E ATRIBUTOS DE QUALIDADE ESTÃO EVIDENTES?

No início dos projetos, a principal preocupação dos arquitetos é explicitar a estratégia – padrões coerentes para tomada de decisão – que deve ser observada nas decisões arquiteturais.

CONSEGUIMOS EXPRESSAR NOSSA ESTRATÉGIA ATRAVÉS DE FITNESS FUNCTIONS?

“Estratégia” precisa ser objetiva e observável, expressa em architectural fitness functions. A arquitetura evolucionária não é emergente, nem baseada em palpites.

QUAL A OBSOLESCÊNCIA TECNOLÓGICA MÁXIMA ADMITIDA?

O “represamento” das iniciativas para modernização tecnológica é uma das maiores causas para a “morte” dos sistemas de software. Mesmo quando tecnologias não agregam “algo novo”, o afastamento da trajetória evolutiva das ferramentas, técnicas e práticas por um tempo prolongado aumenta de maneira exponencial o custo e risco para a mudança, apesar dos custos de oportunidade.

QUAIS ARTEFATOS ESTÃO NA “ZONA DE DOR”? E NA “ZONA DE DESUSO”?

Como já foi dito, transferir acoplamento aferente de algumas implementações concretas para abstrações pode simplificar a manutenabilidade dos sistemas, aprimorando o evolvability. Entretanto, abstrações em demasia, ou para artefatos errados, tornam sistemas mais difíceis de entender e caros para manter.

28 of 29

MANUAL DO ARQUITETO

PÁGINA ⠀28⠀

https://learning.eximia.co/

https://arquiteturadesoftware.online/

29 of 29

FEITO COM 🤍 POR EXIMIACO