A génese de um (bom) design de arquitetura de software

por André Pereira, Backend Developer @ Xpand IT

Quando me ouves dizer que o design de arquitetura é uma fase importante (se não a mais importante) do design de software, aposto que pensas “Claro que é, mas e novidades?”. Não duvido de que a maioria de nós, developers, acredite nisso, mas será que realmente sabemos levá-lo a cabo? E, mais ainda, será que sabemos fazê-lo bem?

A nossa indústria é recente. Andamos a criar programas para correr naquilo a que chamamos computadores há apenas 70 anos. Assim, procuramos constantemente exemplos noutras profissões na tentativa de explicar o que fazemos na criação de design de arquitetura de software. Adotamos nomes e terminologias de profissões que já existem há milhares de anos, como engenheiros e arquitetos; o que acaba por implicar que sabemos o que estamos a fazer, quando a verdade é que não.

Quando adaptámos o termo “arquiteto” para sustentar a nossa indústria, quisemos também copiar alguns métodos dessa profissão: a ideia de alguém que desenha um plano detalhado para os outros interpretarem, na esperança de que o sigam; um equilíbrio entre um artista e um engenheiro, a supervisionar a criação daquilo que normalmente é uma visão singular. Na nossa indústria, esta perspetiva leva a terríveis práticas que culminam na construção de uma visão informativa de como construir o sistema ‘perfeito’, sem considerar que o futuro é fundamentalmente desconhecido.

Pela honra e saúde dos arquitetos de verdade, concordamos que o termo não descreve adequadamente o nosso trabalho. Infelizmente, por enquanto, estamos presos a ele. Assim sendo, o melhor que podemos fazer é redefinir o que este significa no nosso contexto.

A Imprevisibilidade do Futuro

Que atire a primeira pedra quem nunca teve um projeto cujos requisitos se alteraram depois do início da sua implementação. Acredito que não tenhas acabado de mandar uma pedra contra o teu ecrã, não porque isto nunca te tenha acontecido, mas sim porque teres uma pedra ao teu lado seria no mínimo improvável. Trabalhamos num ambiente hostil, e os nossos requisitos variam mais rapidamente do que os daqueles que desenham e erguem edifícios (assim como as técnicas e ferramentas que temos à disposição).

Devemos aceitar que uma vez que o nosso software chega às mãos dos clientes (ou às vezes até antes disso) somos obrigados a reagir e adaptar-nos, visto que não se trata de um artefacto propriamente estático. A nossa mentalidade precisa de afastar-se da criação de um produto final perfeito para nos focarmos em criar uma abordagem na qual os sistemas continuarão a emergir e crescer. É impossível prever cada detalhe do nosso futuro; portanto, em vez de planear todos os desfechos possíveis, devemos permitir-nos mudar, evitando a urgência de ter de especificar cada detalhe.

O Arquiteto-programador

Uma coisa que as pessoas normalmente se esquecem é que os nossos sistemas não acomodam apenas os utilizadores. Abrangem também as equipas de desenvolvimento e operações que trabalham com eles. É escusado afirmar que a felicidade dessas equipas afeta diretamente a qualidade do produto final, e, então, os arquitetos têm a obrigação de garantir que o sistema é ‘habitável’ para os developers também.

Para garantir que os sistemas são agradáveis para os developers, precisamos de entender como as decisões de design de arquitetura de software impactam os seus trabalhos. A melhor forma de adquirir esse conhecimento é trabalhando em proximidade com essas equipas arregaçando as mangas e escrevendo código, fazendo das dores dos developers as nossas – mesmo que apenas por um curto intervalo de tempo. Isto é bem mais eficiente do que fazer uma chamada ou simplesmente dar uma vista de olhos a esse mesmo código.

Não consigo reforçar o quanto eu acho que é verdadeiramente importante que um arquiteto de software trabalhe em comunhão com a equipa. Resumirei alguns dos problemas que podem surgir como consequência do mindset de um arquiteto que não escreve código contra os benefícios de quem o faz.

Ao ver um projeto desde cima podemos construir uma perceção inadequada do seu estado de desenvolvimento. A timeline parece bem. O trabalho está a ser feito. A funcionalidade está a ser construída. Mas estará a vertente técnica a ser cumprida? E a motivação da equipa? Que mais se passa?

• O arquiteto de software perde o domínio sobre as ferramentas e as tecnologias: podemos resumir este ponto em ‘a menos que o arquiteto siga as suas próprias recomendações, poderá estar completamente a leste das repercussões das suas escolhas’. Dito isto, trabalhar com a equipa de desenvolvimento do produto (em vez de ficar retido na sua bolha) é uma excelente oportunidade para conhecer novas e mais sofisticadas tecnologias.
• A visão técnica não se está a cumprir: escrever código a par da equipa é uma boa forma de garantir, através do exemplo, que a visão técnica do projeto é cumprida. É também a melhor forma de garantir que o código não se desvirtua da visão inicial, antes que seja tarde de mais para correr atrás do prejuízo.
• O design de arquitetura de software não acompanha a alternância dos requisitos: já sabemos que não podemos assumir um universo estático em redor dos nossos projetos; a arquitetura e o design normalmente requerem alterações. Ao estar mais próximo da equipa, o arquiteto pode facilmente prever as alterações que se demonstrarão necessárias e reagir rapidamente. Isto consegue-se através da colaboração com a equipa para assegurar a evolução da arquitetura do sistema.
• Os developers frustram-se: este contacto com a equipa é importante para que o arquiteto realmente entenda as necessidades da equipa. Se o plano gera problemas ou se desvia dos requesitos iniciais do cliente, trabalhar próximo da equipa permitirá evitar atrasos de comunicação.

Ao trabalhar em comunhão com a equipa todos estes problemas podem ser facilmente evitados. Se isto não é suficiente para te convencer, dou-te mais alguns benefícios desta metodologia:

• Um melhor entendimento do design de arquitetura de software: quando os arquitetos escrevem código, têm a oportunidade de comunicar, com maior impacto, as ideias e princípios do design aos developers, desbloqueando um maior impacto. A criação de protótipos é outra hipótese viável para demonstrar como os designs das arquiteturas serão implementados na vida real.
• Updates do design em tempo real: arquitetos de software que desenvolvem código podem avaliar a necessidade de procurar alternativas em tempo real. Manter um arquiteto com a equipa garante que este pode contribuir para atacar tópicos de melhoria. Adicionalmente, isto levaria a que houvesse uma ainda menor premência em “sobre-arquiteturar” tudo a priori.

Todos a Remar na Mesma Direção

Todas as empresas têm objetivos definidos, seja a nível global ou local, e isso pode não incluir a tecnologia sequer: objetivos estratégicos. Esses objetivos são estabelecidos para apontar a direção na qual a organização segue, e, portanto, a tecnologia deverá estar alinhada com os mesmos.

O arquiteto de software tem um papel importante para garantir que todos remam na mesma direção em prol de um objetivo comum. Assim, ele deverá mapear os objetivos para um ponto de vista técnico, o que pode requerer a consideração de alguns trade-offs. Para cumprir a tarefa, o arquiteto de software deverá definir um conjunto de práticas e princípios para guiar o desenvolvimento.

Princípios são regras que tendem a alinhar a perspetiva técnica com objetivos mais amplos, e estão sujeitos a alterações. Por exemplo, se um dos objetivos da empresa é diminuir o time to market de novas ferramentas, deverá definir-se um princípio que assuma que as equipas têm controlo total sobre o tempo útil do software até à sua entrega quando pronto, independentemente de qualquer outra equipa.

Práticas são a forma como garantimos que os princípios são levados a cabo. São um conjunto de instruções detalhadas e práticas para executar certas tarefas. Frequentemente são específicas para uma determinada tecnologia e devem ser específicas o suficiente para que qualquer developer as entenda. As práticas podem incluir instruções de código, que todos os dados que necessitem de ser captados centralmente, ou que o HTTP/REST seja o standard como forma de integração. Tal como os princípios, por vezes as práticas refletem obstáculos dentro da tua organização. Por exemplo, se apenas suportam CentOS, isto terá de refletir-se nas vossas práticas.

O teu trabalho ainda não está feito

Após o início do desenvolvimento do projeto, o arquiteto não deve desaparecer no ar para apenas se tornar um fantasma do passado. Se um dos trabalhos do arquiteto é garantir que exista uma visão técnica, então o de management é garantir que o que estamos a construir corresponde a essa visão, e é necessário desenvolver a visão.

A governação garante que os objetivos da empresa são atingidos através da avaliação das necessidades, condições e opções dos acionistas; apontando a direção através da priorização e tomada de decisão; e monitorizando a performance, conformidade e progresso contra direções e objetivos pré-estabelecidos – COBIT 5.

 

Os arquitetos são responsáveis por muitas coisas. Devem assegurar que há um conjunto de princípios que orientam o desenvolvimento, e que esses princípios estão de acordo com a estratégia da organização. Devem também garantir que tais princípios não requerem práticas de trabalho que torne os developers miseráveis. Precisam de ser mantidos em constante atualização com tecnologias novas e é crucial que saibam quando fazer os trade-offs apropriados. Para além disso, é essencial assegurar que os colegas com quem trabalham percebam que decisões estão a ser tomadas; e que é da responsabilidade deles levá-las a cabo. Ah, e já falámos sobre isto: precisam de passar tempo com essas equipas para entender o impacto das suas decisões.

Pedir tudo isto e ainda que o arquiteto trabalhe em governação parece demasiado, certo? Pois sim, mas acaba por ser essencial também, e não significa que seja um trabalho a solo. Normalmente a governação é um trabalho de grupo. Pode ser através de uma conversa informal, ou numa mais estruturada e formal reunião com representação de toda a equipa.

Conclusões

Estarás, provavelmente, a perguntar-te porque passei todo este tempo a dissertar sobre os arquitetos quando disse no título que o assunto seria o design da arquitetura de software. A resposta é tão óbvia como a pergunta: boas arquiteturas advêm de bons arquitetos. Definir características nucleares acerca de arquitetos de software define, subsequentemente, atributos essenciais para uma boa arquitetura (como já deves ter percebido). E, claro, há muito mais ainda a dizer sobre arquiteturas, mas não poderíamos deixar de mencionar os seus designers; porque boas arquiteturas não definem bons resultados se não forem desenhadas e aplicadas com o mindset adequado.

Referimos que os profissionais na nossa indústria não são os mesmos arquitetos que desenham edifícios, como por vezes podem parecer. Assim, tentámos redefinir aquilo que significa ser arquiteto no nosso contexto. E, portanto, para finalizar, vou resumir o que identifiquei como qualidades essenciais para um arquiteto de software:

• Visão: garantir que há uma visão técnica para o sistema, comunicada com clareza, que ajudará a corresponder aos requisitos da organização e dos clientes.
• Empatia: entender o impacto das decisões tanto nos colegas como nos clientes.
• Colaboração: contactar com o máximo de colegas e pares possível a fim de definir, refinar e executar a visão.
• Adaptabilidade: assegurar que a visão técnica se altera sempre que a organização ou os clientes requeiram.
• Governação: garantir que o sistema a ser implementado serve o propósito da visão técnica.