Esteja sempre por dentro das novidades!

Arquitetura evolutiva: O segredo da arquitetura ágil

A arquitetura de softwares é muito mais dinâmica do que imaginamos, quando olhada apenas superficialmente. Em especial em tempos de aceleradas mudanças do digital, em que produtos e soluções demandam alterações e melhorias constantes, precisamos entender a disciplina com uma abordagem mais racional para conseguir absorver essas transformações.
A resposta para encontrar este “racional” está descrita no que chamamos, hoje, de “arquitetura evolutiva."
Considerando as necessidades atuais do desenvolvimento de produtos, precisamos também entender a arquitetura como uma disciplina que deve ser fluente para todas as pessoas de um time que trabalhe nos moldes das operações digitais, segundo os princípios do Agile. Ou seja, uma equipe multidisciplinar, autônoma e dedicada a um fluxo de valor de ponta a ponta.

Cada profissional dessa equipe, com suas diferentes habilidades e conhecimentos, pode e deve contribuir muito para o enriquecimento de um projeto e amadurecimento da arquitetura, mas, para isso, precisa ter auxílio e orientação de quem atua com arquitetura de softwares. Esse é o perfil capaz de orientar e organizar as ideias que surgirem na equipe, garantindo coerência na evolução sistemática da arquitetura. Esse é um dos grandes desafios dessa atuação nos tempos digitais; essa pessoa tem que buscar transmitir seus conhecimentos de forma tão eficaz que o time se torne fluente na disciplina, e ela, quase desnecessária. Essa deve ser a nossa missão.

Mas é preciso deixar claro que não é apenas profissionais de arquitetura que têm que se comprometer e o software que precisa evoluir. É necessário que haja uma disposição verdadeira de cada integrante do time para aprender e destravar seu potencial não apenas no que diz respeito à disciplina de arquitetura evolutiva, mas também no entendimento de negócios e nos demais conhecimentos de seus pares.

O primeiro desafio para estabelecer um ambiente propício para a adoção da arquitetura evolutiva, então, é desfazer os silos de fato e estimular cada vez mais a troca de experiências entre todos as pessoas envolvidas na concepção de um produto digital. O time deve ter em mente que o poder de desenvolver o melhor resultado virá da “inteligência coletiva”.

Complexidade versus Simplicidade

Ao adotar a arquitetura evolutiva, nosso objetivo é permitir que o software seja modificado de maneira sistemática e evoluído conforme as necessidades. Para isso, controlar o aumento da complexidade do software é primordial. Um dos primeiros sintomas que pode ser percebidos ao analisar uma arquitetura de software que cresceu sem esse controle é justamente a perda de velocidade para absorver mudanças.

Quando estamos trabalhando em um software, precisamos ter atenção à complexidade que constantemente inserimos no sistema, pois existem armadilhas em não observar com atenção este aumento sistemático. Podemos dividir toda a complexidade de um sistema em dois grandes grupos:

A complexidade essencial: é aquela da qual não temos como fugir. A cada nova funcionalidade que adicionamos, assumimos uma complexidade essencial que decorre justamente do problema que nos propomos a resolver. Ou seja, se você está criando um sistema financeiro, não há como não assumir a complexidade de entender como as taxas e alíquotas são calculadas.

A complexidade acidental: por sua vez, só existe em função da estratégia que escolhemos para resolver um determinado problema e não do problema em si. Ou seja, você poderia ter evitado esta complexidade se tivesse escolhido a estratégia mais simples ou pelo menos a mais adequada ao momento da sua arquitetura.

KISS

Uma dica para se manter a complexidade dentro do planejado é seguir o princípio do KISS (Keep It Simple). Esta é uma prática bem conhecida que tenta eliminar a complexidade acidental que é produzida sempre que procuramos fazer algo mais “sofisticado” do que o necessário.

Quando possível, mantenha as coisas simples. Para isso, temos que observar um padrão de comportamento humano contra o qual precisamos lutar diariamente: o nosso instinto de complicar. Isso é da nossa natureza, por isso, é necessário ter foco e autocontrole para fazer apenas o necessário.

Lembre-se: uma boa arquitetura faz o problema parecer simples, lidando com a complexidade inerente e desviando ao máximo da complexidade acidental.

A refatoração

Uma cultura de experimentação é baseada na premissa de que é praticamente impossível acertar de primeira. Esta é a graça da evolução! É a possibilidade de melhorar a cada volta. A dificuldade neste ponto é ter disciplina para fazer evoluções conscientes, buscando aperfeiçoamento com foco claro em alguma necessidade real, seja performance, reusabilidade, segurança ou outras.

Caso contrário, acabamos ferindo o princípio anterior e refatorando sem um propósito claro só para investir em soluções mais robustas antes de termos certeza do seu real valor para a arquitetura.

A refatoração é um meio de aprender, mesmo que esse aprendizado seja que a solução não é funcional em determinado cenário e que devemos desistir dela. É uma necessidade para que nos mantenhamos flexíveis arquiteturalmente.

A reversibilidade

Garantir que nossas adições à arquitetura sejam possíveis de serem desfeitas é primordial para que possamos refatorar continuamente. Como dito, uma cultura de experimentação só vai ser implementada quando não tivermos mais dificuldades em dar um passo atrás e desistir de alguma solução que trouxemos para nossa arquitetura.

Naturalmente, não estamos falando de grandes mudanças. Nossa intenção é promover uma substituição contínua e gradual de funcionalidades já existentes, buscando validar hipóteses e, assim, aproveitar o esforço investido.

Último momento de responsabilidade

Encontrar o perfeito equilíbrio entre experimentação, refatoração e o ponto ideal para tomar determinadas decisões é um dos grandes desafios da arquitetura evolutiva. Queremos aproveitar o benefício de atrasar uma decisão o máximo possível para ter mais informações e certezas, mas devemos cuidar para que isso não prejudique o andamento do projeto. Podemos quantificar o custo de uma decisão quando analisamos seus desdobramentos.

Olhe além da perspectiva técnica

Existem muitas vantagens em adotar um racional evolutivo para sua arquitetura de software, porém, é importante destacar que, normalmente, essas arquiteturas são diretamente focadas em reuso e, portanto, levam em consideração não apenas fatores técnicos, mas também questões como produtividade e, consequentemente, questões econômicas.

Isso significa que você não deve pensar somente na parte técnica ao definir o futuro da sua arquitetura de software, mas também compartilhar as decisões e buscar perspectivas diferentes que sustentem questões relativas a produto, pessoas e processos. É necessário acompanhar atentamente o crescimento do produto e buscar um entendimento amplo de negócio junto aos seus pares. Assim, você garante que o que está sendo desenvolvido, funcional ou não-funcional, esteja de acordo com o seu real propósito.

Além disso, é importante não negligenciar o desenvolvimento das pessoas do seu time. Desenvolvimento esse que você deve apoiar, conforme já mencionado neste texto. Divida o seu tempo para, efetivamente, exercer o papel de guia que você precisa ser para seus liderados e lideradas.

Lembre-se que arquitetura é uma disciplina e não um papel para ser executado pelo “arquiteto”. Como disciplina, é formada por diferentes áreas que devem ser equilibradas no dia a dia. São elas:

Delivery: é o como fazer, ou os aspectos práticos que envolvem a melhor maneira de executar diferentes atividades, garantindo que os processos de teste, CI/CD e definições estratégicas do ponto de vista operacional sejam realizados corretamente.

Guidance: compreende os aspectos de formação e direcionamento contínuo das pessoas para realização das suas atividades. A preocupação com esta disciplina é tornar todo seu time apto a entender arquitetura. A melhor maneira de criar um guidance é por meio de code-reviews e desenvolvimento em pares, tornando o tempo de produção também um tempo de formação.

Management: é o porquê e o que fazer. Trata de questões que envolvem a visão macro da situação da arquitetura. Para isso, precisamos criar uma estrutura de gestão que nos permita compartilhar com os demais membros do time assuntos como riscos e roadmap, garantindo um melhor entendimento do contexto do projeto para todos.

Para que você consiga manter a arquitetura sob controle, apoie-se nas ferramentas conhecidas. Não é necessário reinventar a roda, lembre-se de usar processos mais simples para fazer com que o ciclo de aprendizado e experimentação sejam bem-sucedidos. Realize retrospectivas, kaizens e PDCAs (Plan Do Check Act) constantemente. Ritos como estes são insumos valiosíssimos para alimentar o racional que você irá usar para definir os próximos passos de uma arquitetura evolutiva.

Por fim, não trabalhe para evoluir apenas a sua arquitetura ou produto, mas como profissional também em constante evolução.

< Post mais antigo Post mais novo >