Desenvolvimento de software é atividade cada vez mais relevante. É difícil imaginar qualquer atividade, em qualquer empresa, em qualquer segmento, que não seja suportada, direta ou indiretamente, por algum tipo de sistema digital. Software bem-feito é, cada vez mais, premissa para a competitividade. Logo, mesmo empresas que não se declaram tecnológicas, tem a tecnologia como competência essencial. Nesse contexto, arquitetura de software ganha relevância, bem como a atuação do arquiteto.
Todo software tem sua arquitetura. Algumas “emergiram” de forma não supervisionada e, por isso, têm qualidade questionável. Software bem-feito tem boa arquitetura e é difícil que isso aconteça sem a atuação de alguém competente como responsável.
O que é arquitetura de software
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.Arquitetura de software pode ser definida como a organização fundamental de um sistema, seus componentes, a relações entre eles e o ambiente que guia seu design e evolução. (IEEE Standard 1471)
A arquitetura de software de um programa ou sistema computacional é a estrutura ou estruturas do sistema que abrange os componentes de software, as propriedades externamente visíveis desses componentes e as relações entre eles (Bass, Clements e Kasman)
A arquitetura de um software não é um conjunto de diagramas, produzidos por alguém, frequentemente desatualizados. Os diagramas, aliás, são apenas um modelo, uma representação, da arquitetura real que está ou estará implementada no software.
A relação de arquitetura com design de software
Quando falamos sobre arquitetura, invariavelmente falamos sobre design de software. Entretanto, o oposto não é verdadeiro. As decisões sobre design que são parte da arquitetura de um software são aquelas que tem relação direta com o atendimento dos objetivos do negócio, respeito a restrições e atendimento dos atributos de qualidade.
A decisão de isolar acesso ao banco de dados em uma “classe repositório”, por exemplo, é uma decisão de design, mas, dificilmente será uma decisão de arquitetura. Afinal, dificilmente será fundamento para atendimento dos objetivos de negócio, respeito a restrições e atributos de qualidade. Por outro lado, a adoção de um cache é, quase sempre, uma decisão de arquitetura pois, este componente pode ser a resposta para atender atributos de qualidade como disponibilidade e performance.
Construir um software cloud-ready também é uma decisão de arquitetura, bem como adotar um ou outro fornecedor de nuvem. Aliás, as escolhas do banco de dados, das linguagens de programação, dos frameworks tanto para frontend quando backend também são exemplos de resoluções arquiteturais pois, certamente, terão implicações relevantes para a continuidade do software, logo, condições para atender o negócio e implicações sobre o orçamento (uma das restrições mais comuns).
A maioria das decisões de design são individuais, em conformidade com os acordos estabelecidos pelo time de desenvolvimento e acontecem o tempo todo. Algumas decisões de design relacionadas com a arquitetura, por outro lado, têm impacto maior e são menos frequentes. Decisões arquiteturais raramente são produtos do trabalho individual.
Finalmente, decisões de arquitetura geralmente são mais difíceis e custosas de revisitar. Daí, talvez, venha a definição vaga de Ralph Johnson que utilizei na citação de abertura.
As práticas da arquitetura de software
As decisões de design que tem relação com a arquitetura são tão importantes que, idealmente, devem ser tomadas obedecendo algumas boas práticas. Ou seja, replicando os comportamentos comuns adotados por times eficientes que produzem software de boa qualidade, que atendem os objetivos do negócio, respeitando restrições a atingindo atributos de qualidade.
As práticas de arquitetura de software maximizam a produtividade. Ou seja, a relação entre o valor obtido (desempenho) e o esforço dispensado (empenho). De maneira análoga, boa arquitetura maximiza o resultado, otimizando o investimento. Em termos simples, boa arquitetura de software colabora para melhorar o ROI de iniciativas de desenvolvimento e reduzir o TCO.
As melhores práticas de arquitetura de software invariavelmente acionam as partes interessadas (stakeholders) para explicitar e atualizar os objetivos do negócio que precisam ser atingidos, focando nos resultados e não na forma. Elas também devem diagnosticar, até o último momento responsável, as restrições que devem ser observadas e assegurar que elas sejam respeitadas. Finalmente, também devem inferir os atributos de qualidade que garantem a eficiência no atendimento do negócio e das restrições.
A abrangência da arquitetura de software
As decisões arquiteturais impactam, obviamente, nas atividades de desenvolvimento, mas também tem relação com a manutenção, atualização, entrega (deploy) e operação do software. Por isso, arquitetura de software é parte do esforço de engenharia, que é mais amplo.
A boa engenharia de software, conforme a Google, contempla todas as atividades que habilitam um sistema a suportar as mudanças de escala, ao longo do tempo, sem sacrificar a eficiência. Seguramente, as decisões arquiteturais são parte crucial para o sucesso da engenharia.
A decisão de adotar microsserviços, por exemplo, transfere parte da complexidade de desenvolver um software para sua operação. Há mais o que operar e monitorar e obrigam a adoção de abordagens mais modernas e automatizadas. Não raro, microsserviços é uma tentativa de resolver um problema criando outro pior!
A “estratégia” na arquitetura de software
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.
Quando um time de desenvolvimento adota boas práticas de arquitetura, seus membros seguem uma estratégia comum para suas escolhas e isso é extremamente importante. Afinal, para cada problema tecnológico há uma continuidade crescente de respostas viáveis – com prós e contras – que dificultam o consenso. A alternativa selecionada deve ser aquela que for mais aderente aos objetivos de negócio, restrições e atributos de qualidade.
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.
O arquiteto de software
Todo software tem uma arquitetura. Nem sempre, entretanto, ela é suportada por boas práticas arquiteturais.
Há quem defenda que as boas práticas arquiteturais devem ser reforçadas por todo o time de desenvolvimento e eu concordo com isso. Entretanto, também entendo que algo que é responsabilidade de todos, acaba recebendo cuidados de ninguém. O arquiteto de software, em um time de desenvolvedor de software, é o responsável por garantir que boas práticas de arquitetura sejam adotadas.
O arquiteto apoia os esforços de engenharia de software, tomando decisões que facilitem a gestão do ciclo de vida de um produto tecnológico.
Em um mundo onde especialistas sabem cada vez mais sobre cada vez menos, não se pode esperar que uma única pessoa seja capaz de tomar todas as decisões importantes relacionadas com a arquitetura. Entretanto, parece coerente ter alguém preocupado e responsável por garantir que essas decisões sejam tomadas – este é o papel do arquiteto.
O arquiteto de software é, idealmente, um orquestrador. Ele garante que todas as partes interessadas sejam ouvidas e suas ponderações sejam levadas em conta na formulação da arquitetura. Para isso, elabora e mantém artefatos abrangentes que facilitam o engajamento.
O arquiteto de software deve, de tempos em tempos, revisar a estrutura de componentes e suas relações de um software para garantir que os objetivos do negócio serão atingidos, as restrições obedecidas e os atributos de qualidade atendidos. Além de tudo isso, o arquiteto deve adotar postura “provocativa” para verificar se a entrega está maximizada frente ao melhor custo.
O arquiteto não é, necessariamente, um “dev sênior-sênior”
Em minha experiência, não conheci nenhum arquiteto de software que não tenha sido, também, excelente desenvolvedor. Entretanto, embora exista correlação, não consigo identificar causalidade.
O arquiteto de software precisa de soft skills suficientes para poder interagir com os diferentes stakeholders de maneira qualificada. Além disso, deve ter capacidade de abstração suficiente para representar componentes complexos de maneira compreensível. Finalmente, precisa ter “sensibilidade técnica” para identificar falhas arquiteturais e acionar as pessoas certas para que as decisões sejam as mais assertivas.
A alocação de uma pessoa em atividades de arquitetura pode variar significativamente conforme a complexidade ou os riscos do software que está sendo desenvolvido. Em muitos cenários, o arquiteto tem tempo para escrever código. Outras vezes, as atividades de orquestração podem ser demandantes ao ponto de que não sobre tempo para escrever código em quantidade relevante.
Este é o início de uma longa jornada…
Gosto muito da ideia de dar passos consistentes na direção certa, o tempo todo. Nesta introdução, tentei consolidar impressões sobre arquitetura de software, suas práticas e as atribuições de um arquiteto. Nos próximos capítulos, vou apresentar algumas “boas práticas” de arquitetura que tenho vivenciado como arquiteto e consultor.
// TODO
Antes de avançar para o primeiro capítulo, recomendo as seguintes atividades:
- Reflita sobre as práticas de arquitetura de software que você tem presenciado. O que tem funcionado? O que não tem gerado os resultados esperados?
- Você consegue relacionar os principais componentes do software que está desenvolvendo, suas responsabilidades e a forma como estes se relacionam?
- Você consegue relacionar os objetivos de negócio que precisam ser atingidos usando o software que está ajudando a desenvolver? Conhece as principais restrições? Saberia explicitar os atributos de qualidade?
“A integridade conceitual é essencial à qualidade do produto. Ter um arquiteto do sistema é o passo individual mais importante para alcançar a integridade conceitual.” (O Mítico Homem-Mês, Cap. 19, p. 249. parag. 2)
“Ninguém ama o portador de más notícias” SÓFOCLES
Citação de introdução do Cap 14 – Incubando uma Catástrofe em O Mítico Homem-Mês.
“Cada bala tem seu alvo.” Guilherme III da Inglaterra – Príncipe de Orange.
“Na minha experiência, muitas das complexidades que são encontradas no trabalho em sistemas são sintomas de problemas organizacionais. Tentar modelar essa realidade com programas igualmente complexos é, na realidade, preservar a desordem em vez de resolver problemas.” Lars Sodahl da MYSIGMA Sodahl and Partners
Muito boa essa citação!
Sobre o paragrafo: “O arquiteto de software precisa de soft skills suficientes para poder interagir com os diferentes stakeholders de maneira qualificada. Além disso, deve ter capacidade de abstração suficiente para representar componentes complexos de maneira compreensível. Finalmente, precisa ter “sensibilidade técnica” para identificar falhas arquiteturais e acionar as pessoas certas para que as decisões sejam as mais assertivas.”
“O projeto da Torre de Babel falhou por falta de comunicação, e por causa dessa falta, a organização falhou.” O Mítico Homem-Mês Capitulo 7 – Por que a Torre de Babel Falhou?