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.
O que é arquitetura de software
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 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.
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).
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 melhores práticas de arquitetura resolvem de maneira leve os principais trade-offs – direções conflitantes que precisam ser observadas – que emergem no levantamento dos objetivos e das restrições. Por exemplo, disponibilidade – um atributo de qualidade – conflita com segurança – uma restrição, afinal, disponibilidade implica em adição de componentes que ampliam a “superfície de ataque”.
A abrangência da arquitetura de software
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 “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.
O arquiteto de software
Todo software tem uma arquitetura. Nem sempre, entretanto, ela é suportada por boas práticas arquiteturais.
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 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”
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.
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?
Elemar, você pode relacionar mais alguns exemplos concretos de decisões de design? Em parágrafo anterior você cita a criação da classe repositório como uma decisão de design e a escolha por cloud-ready como sendo decisão de arquitetura. Você pode exemplificar outras decisões de design individual e decisões de design na arquitetura? Na minha opinião a afirmação de que “elas tem impacto maior e são menos frequentes”, ficou muito vago e abstrato.
Concordo. Pra mim não ficou bem claro a distinção entre decisões de design e decisões arquiteturais.
Elemar, que tal adicionar em algum ponto do texto qual é o papel do Engenheiro de Software e as diferentes responsabilidades em relação a um Arquiteto?
Concordo, existe uma dificuldade em distinguir as responsabilidades deste dois profissionais.
Certa vez li um texto que dizia que essa confusão existe porque o conceito de Arquiteto e Engenheiro aqui no Brasil é o exato oposto do que é nos EUA e Europa, pra explicar melhor, lembro que o texto tinha uma tabela mais ou menos assim:
Particularmente, acho que a definição brasileira esta “menos errada”.
Uma questão que me vem aqui é a dificuldade para o alcance do equilíbrio entre as responsabilidades do Arquiteto e quando ele não escreve mais código de forma a se distanciar da realidade dos desenvolvedores e começar a apenas definir modelos bonitos no papel, mas que estão longe da realidade do dia a dia das equipes.
Uma coisa a se deixar claro aqui é que o diferencial é a existência de pessoas competentes. As vezes essa pessoa competente desenha uma boa arquitetura sem necessariamente possuir o título de arquiteto.
Hoje eu penso muito que tudo é sobre relacionamentos(ligações e conexões), desde o menor nivel(atributos) até o mais amplo (entre sistemas)
Como uma classe se relaciona com outra, uma função, um componente, container, sistemas.
A Arquitetura é como as coisas se relacionam.
Sempre levo esse como o feijão com arroz da arquitetura. Alta coesão e Baixo acoplamento. Se o trabalho de um arquiteto tivesse que ser reduzido a apenas uma atividade, essa atividade seria manter o equilíbrio destes dois itens.
Acredito que isso possui grande valor em projetos de software, pois também habilita maior testabilidade.
Outro ponto que anda junto com baixo acoplamento é a coesão interna das partes desacopladas, afinal software precisa de bons relacionamentos.
Há um breve post do Kent Beck que sugere que arquitetura e design sejam “apenas design”, ou seja, que essa divisão em níveis entre o que seria arquitetura e design não faria sentido.
Segue o link:
https://kentbeck.substack.com/p/elements-all-the-way-down
Isso é um fato, sou testemunha de casos em que a escolha da arquitetura foram apenas por saber que muitas empresas no mercado tem usando por exemplo, aplicação da modinha atual uma aplicação front-end e outra back-end baseada na arquitetura SOFEA, mas que talvez não atenda a necessidade do cliente e o seu negocio, importante alguém competente para desenhar boa arquitetura.
Discordo em partes.
Frequentemente acredito que é causalidade.
Não vejo uma empresa contratando arquiteto que não tenha forte background de desenvolvimento.
A causalidade entra aqui: Muitas vezes o Dev sênior não encontra uma maneira de progressão de carreira desejada e acaba tornando-se Arquiteto.
Há empresas que possuem papéis de Dev Master, Dev Principal etc. dando um horizonte maior para esses excelentes Desenvolvedores. Todos ganham.
Daniel, um exemplo de decisão individual de design é quando um programador decide utilizar algum padrão de projeto com o intuito de completar uma tarefa. Estou correto?
Além de melhorar o ROI, uma boa arquitetura necessita ter um custo de manutenção (TCO) baixo.
Seria bom ter uma definição de design de software, antes de definir quais são e não são arquiteturais?
Vejo muitos softwares construídos com base na “carteirada driven architecture”, as muitas vezes até existe um profissional competente por trás da solução, mas a companhia tem a necessidade vender a licenças de software A ou B ou cloud A, W ou G e acaba empurrando contra a vontade do Arquiteto o melhor cenário para o cliente. Eu já fui parte de um processo assim, o que me restou foi abandonar a consultoria e muitas vezes fui taxado de “onesticida” por avisar ao cliente que a prática poderia custar mais caro com esse cenário.
Ainda existe o arquiteto de software nas empresas atualmente? Uma pessoa deve ser responsável por toda a arquitetura de um sistema ou isso deveria ser tarefa pra vários ou talvez pra equipe inteira?
Li um artigo recente sobre o processo de arquitetura em uma grande empresa em que todo o time ajudou a desenhar a arquitetura.
A máxima não existe bala de prata também vale para microserviços. Apesar de suas vantagens, dependendo do tamanho da empresa e sua visão de crescimento uma arquitetura de microserviços atrapalha mais que ajuda
Em times com profissionais muito experientes, a arquitetura pode ser eficiente para o cenário mas não estar aderente ao planejamento estratégico da empresa.
Eu acho que isso se encaixa muito com o modelo Dreyfus de aquisição de competência. Quanto maior seu conhecimento, mais capaz de enxergar o “Big Picture” você se torna. Acho muito difícil (diferente de impossível) uma pessoa sem o tempo de experiência necessário ser capaz de possuir o alto grau de abstração necessário para executar a tarefa de arquitetura.
O trabalho de arquitetura consiste em proposição, avaliação de riscos, custos e impactos e posterior tomada de decisão.
Sem sólidos conhecimentos técnicos, o arquiteto vira apenas uma fonte de eco e propagador de ruídos (essa é minha experiência, pelo menos).
Esses conhecimentos técnicos podem ser focados em outras áreas, que não desenvolvimento (infraestrutura, banco de dados, sistemas embarcados, etc. – dependendo do negócio).
Julgamento sem conhecimento é palpite vazio.
Seria correto afirmar que em softwares com arquitetura problemática, antes de agir devemos entender quem está sendo mais afetado são a regra de negócio, as restrições ou a qualidade?
É muito comum no processo de desenvolvimento do frontend começar a projetar o sistema a partir das ferramentas que um framework disponibiliza ao invés de primeiro entender quais são os desafios que precisam ser resolvidos a nível de arquitetura.
Sim concordo. Diria que uma boa arquitetura facilita a construção de um software bem-feito.
Arquitetura de Software é o que delimita até onde os desenvolvedores de uma solução, podem exercer sua criatividade, sem que causem mais danos do que benefícios.
Uma definição que mais me chamou atenção foi a do Clements: “The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them and properties of both.”
Gostaria muito de saber sua opnião sobre essa definição. 😉
Concordo totalmente.
Em cenários onde a arquitetura é ruim, perdas financeiras ocorrem em um curto prazo devido a vários fatores: indisponibilidade da aplicação, bugs, maior tempo para entrega de mudanças requisitadas pelo negócio e, consequentemente, impactando no resultado da empresa.