Então, o que é Arquitetura para Agilidade?

Uma forma didática de definir um conceito é começar pelo que ele não é. Portanto, na Seção 1, o foco é o que não é uma “arquitetura para agilidade”. Na seção 2, um caso, inspirado em uma história real, explora o que chamaríamos de “ arquitetura para anti-agilidade ”. Por fim, a seção 3 define o conceito.

___________________________________________________________________________________________________________

 

1. O que não é Arquitetura para Agilidade?

Como sempre em tecnologia da informação, existem muitos chavões em torno de um determinado conceito abstrato e “arquitetura para agilidade” é mais um caso. Lembre-se que o conceito de “Arquitetura para Agilidade” está relacionado à capacidade de uma determinada organização se mover no espaço do problema, de tal forma que diferentes e viáveis arquiteturas de produto ​​(talvez mudando a forma como os componentes de um produto estão ligados – sua arquitetura, enquanto mantém os conceitos centrais de projeto – e, portanto, o conhecimento básico subjacente aos componentes – intocados [2]) são avaliados para um determinado conjunto de requisitos funcionais [1]. Em outras palavras, está relacionada à leanness e à flexibilidade da organizaçãoPor esse motivo, não é definida por uma prática ou um conhecimento específico em um programa ou projeto da organização, que pode incluir: (1) o uso de uma prática ágil, por exemplo, o Scaled Agile Framework (SAFE), onde um architectural runway pode estar em constante desenvolvimento; (2) alguma interpretação e aplicação do conceito de microservice; (3) a avaliação e o uso de alguma tecnologia do tipo broker, sendo o Kafka a mais conhecida; e (4) a compreensão e o uso do projeto orientado a domínio (DDD).

2. Um caso ou uma “arquitetura para anti-agilidade”

Considere uma organização de médio / grande porte na qual o Chief Data Officer (CDO) trabalha como parceiro do Chief Information Officer (CIO). Ao fazer isso, o CDO decidiu que os dados mestres – incluindo um subconjunto dos dados mestres, chamados de dados de referência (por exemplo, gêneros) – devem ser tratados de forma centralizada. Além disso, o CDO também faz parte do seu orçamento com o objetivo de fornecer um conjunto de microservices, com base em REST, para permitir a recuperação dos dados de referência de forma centralizada, por qualquer sistema da organização.

Enquanto isso, o CIO estava trabalhando na renovação do mais importante sistema da organização, chamado ABC, o qual era o canal de transação mais lucrativo da organização. Além disso, o ABC precisava dos dados de referência de gênero.

Neste momento, deve estar claro que a organização restringiu a arquitetura do produto, pois havia uma única opção para recuperar dos dados de referência de gênero. Além disso, a arquitetura da organização foi estampada na arquitetura do ABC, uma vez que havia chamadas REST entre o ABC e os sistemas do CDO espelhando uma parceria entre o CDO e o CIO [1].

Complementarmente, havia uma dependência (dependency) entre os dois sistemas caracterizada pelas chamadas do tipo requisição-resposta (baseadas em REST) e sua estrutura de dados. Em termos de acoplamento (coupling, quão os módulos são interdependentes), isso é categorizado como uma dependência fracamente acoplada (loosely-coupled dependency), uma vez que compartilha a mesma estrutura de dados (veja a Fig. 1). Consequentemente, as equipes do CDO e do CIO devem se comunicar com foco na estrutura de dados, bem como cronogramas para marcos principais. Adicionalmente, como as chamadas REST para o sistema do CDO não tinham contingência no ABC (conforme prescrito pela parceria CDO / CIO), o sistema do CDO se tornou o sistema mais importante da organização, então a sua disponibilidade deveria ser o mais próximo possível de 100% (o que dramaticamente aumenta seu custo). 

Fig. 1 Visão esquemática da dependência e do acoplamento.

Nesse cenário, inspirado em um caso real, como vimos, a arquitetura da organização foi estampada na arquitetura do produto ABC (evidência do espelhamento, mirror evidence[1]) resultando no que chamaríamos de uma “arquitetura para anti-agilidade”. Embora do ponto de vista da ciência da computação os dois sistemas estivessem fracamente acoplados (com base em microservices usando chamadas REST do tipo requisição/resposta que compartilham a mesma estrutura de dados em diferentes contextos limitados), do ponto de vista da engenharia, grosso modo, como diferentes equipes foram acopladas (o progresso deveria ser acordado passo a passo), o ambiente executável do ABC foi fortemente acoplado ao ambiente executável do CDO, uma vez que o ABC era altamente sensível às perturbações nos sistemas do CDO. Na verdade, os sistemas do CDO não eram o núcleo de negócios da organização, muito pelo contrário.

 

O que é Arquitetura para Agilidade?

Elaborando o caso anterior, do ponto de vista do programa e do projeto, a dependência da equipe do CIO, que trabalha no ABC, da equipe do CDO pode diminuir a produtividade devido à necessidade de um subconjunto dos dados mestre, ou seja, gêneros nas transações de negócios. Portanto, é perfeitamente
legítimo aplicar um “critério de decisão 
para dependência” (dependency decision criteria), no qual tal subconjunto dos dados mestre é definido no ABC de forma independente. Nesse caso, os dois sistemas são desacoplados (uncoupled) em relação aos gêneros nas transações comerciais, veja a Fig. 2. 

Fig. 2 Visão esquemática da remoção da dependência, uncoupling, em transações de negócio.

Este é um cenário ilustrativo em que a organização pode se mover no espaço do problema [1] na tentativa de avaliar diferentes arquiteturas que podem resultar em melhores produtos. Em particular, tal arquitetura possibilitaria maior agilidade no sentido de que o sistema ABC poderia ter sua evolução definida em seu próprio ritmo. Além disso, do ponto de vista do ambiente executável, apenas a disponibilidade do ABC seria relevante. Eventualmente, as integrações com outros sistemas que existissem na organização seriam avaliadas no momento adequado, não adiante (atrasando decisões que não seriam obrigatórias). 

Assim, pode-se concluir, grosso modo, que “Arquitetura para Agilidade” é aplicar um conjunto de adequados “critérios de decisão para dependência” (dependency decision criteria) na avaliação de arquiteturas possíveis para um determinado conjunto de requisitos funcionais, talvez resultando no desafio da arquitetura da organização e, até mesmo, de suas políticas. 

Uma vez que o ABC está em produção e trazendo valor para a organização, a parceria CIO / CDO decidiu aplicar um conjunto de adequados “critérios de decisão para dependência” para garantir que o domínio de gênero esteja de acordo com os dados mestre armazenados pelo CDO. Tal conjunto de “critérios de decisão para dependência” apontou para um dos dois chapéus de um “evento”, a saber, “replicação”. Destaca-se que eventos possuem dois chapéus: (1) um chapéu de notificação que aciona serviços e (2) um chapéu de replicação que copia dados de um serviço para outro. Neste caso, os dois sistemas estão desacoplados (decoupleddo ponto de vista da ciência da computação, um tipo menos rigoroso de acoplamento fraco) em relação aos gêneros nas transações comerciais (ver Fig. 3), uma vez que os eventos de gêneros são trocados por meio de um “tópico” sem que os sistemas se conheçam, eles devem saber apenas a estrutura de dados replicada. 

Fig. 3 Visão esquemática do desacoplamento, decoupling, da dependência.

Há alegações de que eventos e as ferramentas relacionadas, por exemplo, um broker de alta disponibilidade, podem lidar com todas as necessidades de comunicações entre serviços. Aqui, somos menos gerais, argumentando que o chapéu de “replicação” de eventos é um capacitador fundamental para a “arquitetura para agilidade”. No mesmo caso real, um antipadrão do chapéu de “replicação” foi observado: o uso de diferentes “tópicos” para trocar o mesmo “evento”. Por exemplo, o CDO definiu diferentes estruturas de dados e “tópicos” para gêneros, visando específicos sistemas. Chamamos isso de antipadrão de “tópico ponto a ponto” e, obviamente, deve ser evitado. 

 

Conclusão

Em resumo, “Arquitetura para Agilidade” é aplicar um conjunto de adequados “critérios de decisão para dependência” na avaliação de arquiteturas possíveis para um determinado conjunto de requisitos funcionais, resultando talvez no desafio da arquitetura da organização e, até mesmo, de suas políticas. O que acabou por ser um fator crucial para a inovação arquitetônica, ou seja, a mudança de como os componentes de um produto são interligados – sua arquitetura, enquanto mantém os conceitos centrais de projeto – e, portanto, o conhecimento básico subjacente aos componentes – intocados [2]. Do ponto de vista da engenharia, o chapéu de “replicação” de eventos e a relacionada técnica de desacoplamento têm se mostrado um capacitador fundamental para a “Arquitetura para Agilidade”. 

 

 

Referências

[1] Arquitetura para Agilidade ou “ Espelho, espelho meu, existe alguém mais belo do que eu? ” –  Alessandro Gerlinger Romero

[2] Henderson, R. e KB Clark (1990) “Inovação arquitetônica: a reconfiguração de tecnologias de produto existentes e a falha de firmas habituais”, Administrative Sciences Quarterly, 35 (1): 9–30.