Parte II – Arquitetura
As diversas definições de arquitetura de software, compiladas pelo Instituto de Engenharia de Software da Universidade Carnegie Mellon [1] sugerem que essa expressão não possui um significado óbvio quando examinada isoladamente. Embora os termos "arquitetura" e "software" possuam significados delineados de forma precisa, sua combinação intrínseca depende do contexto específico no qual são aplicados.
Gregor Hohpe postula que qualquer software possui uma arquitetura, mesmo que não seja intencional. Essa arquitetura deveria impulsionar a eficiência das equipes de engenharia ao permitir o desenvolvimento paralelo e a avaliação dos componentes criados. Além disso, sustenta-se que nenhuma arquitetura é perfeita e que sempre existe uma combinação de escolhas a ser considerada, sendo o contexto o princípio organizador de todas essas decisões.
A documentação de arquitetura de software deve conter as decisões não triviais e sempre fornecer ao leitor o raciocínio por trás de cada escolha realizada, observando o contexto que serviu como catalisador. Além disso, a documentação deve enfatizar o que é essencial, diminuir a ênfase no que é desnecessário e descrever as limitações de uma escolha arquitetônica. É fundamental reconhecer que toda decisão importante tem suas desvantagens.
O autor alerta que as decisões custosas demais para serem revertidas posteriormente devem ser decididas logo no início do projeto, a fim de evitar a paralisação do progresso devido à análise de cada novo elemento introduzido. Citando Martin Fowler, Hohpe esclarece que uma das tarefas cruciais dos arquitetos de software é eliminar a irreversibilidade do design de software por meio de abstrações [2], padrões e paradigmas de desenvolvimento, visando minimizar as decisões irreversíveis no início do processo. Caso o nível de conhecimento das tecnologias pela equipe de engenheiros seja insuficiente, é possível adotar uma arquitetura evolutiva, que se desenvolve à medida que a compreensão sobre essas ferramentas cresce.
A arquitetura de software abrange mais do que componentes e suas interrelações. É preciso adotar uma abordagem sistêmica, enfatizando os relacionamentos e como cada estrutura age como meio para se atingir um comportamento desejado. Nesse sentido, técnicas como os ciclos de retroalimentação negativa podem ser aplicadas atuando como uma autorregulação dos sistemas por meio dos relacionamentos entre os componentes projetados. O foco no comportamento também deve ser refletido na documentação produzida, onde ele deve ser o aspecto mais relevante, em vez de estruturas estáticas.
Controlar o software legado também é um desafio na arquitetura de software, e a chave para evitar a obsolescência desses sistemas é manter sua agilidade. Um sistema não é ágil se ninguém puder modificá-lo. Esse receio de mudanças é justificado quando não há práticas e técnicas de operação adequadas, falta de métricas produtivas e implantações esporádicas. Fowler afirma: "se algo dói, faça mais vezes" [3]. Nesse contexto, tarefas problemáticas devem ser realizadas frequentemente, de modo que a automação seja imposta.
Para uma arquitetura de software em operações em grande escala, o autor enfatiza a necessidade de ampla automação, desde processos burocráticos como aprovações em solicitação de infraestrutura, até pipelines para implantação de aplicações. O que não puder ser automatizado deve ser convertido em sistemas self-service, simplificando atividades rotineiras e previsíveis. Uma estratégia possível para a automatização e desse tipo de sistema é a construção de interfaces com validações integradas ao ciclo de desenvolvimento de software, incluindo o uso de códigos boilerplate para novas aplicações e configuração de serviços de infraestrutura. Deve-se também codificar o conhecimento tácito em scripts e ferramentas, evidenciando esses processos e facilitando a transferência de conhecimento. Por fim, sistemas automatizados para processos amplamente padronizados e explícitos facilitam a auditoria de conformidade.
A arquitetura de software implica a tomada de decisões de design para evitar que os desenvolvedores exerçam criatividade desnecessária. Isso significa que determinados processos devem ser previamente estabelecidos e mantidos como padrões de modo a simplificar a operação de software e liberar as equipes de engenharia para aquilo que promove a diferenciação de negócios da empresa. A padronização de componentes em TI simplifica as operações, permite a economia de escala e economiza recursos financeiros devido ao aumento do poder de compra com os fornecedores.
Essa padronização deve ser considerada em dois níveis: o nível inferior, onde deve-se buscar o máximo de reaproveitamento, já que nem sempre é o diferencial da empresa, e o nível superior, com software desenvolvido internamente, que fornece o verdadeiro valor e a diferenciação competitiva no mercado. Há um elemento de conformidade, no qual poucas mudanças ocorrem nos níveis mais baixos, tornando mais fácil a padronização com um conjunto comum de ferramentas.
Durante a elaboração de diagramas de arquitetura de software, seja utilizando modelos C4 [4] ou outras notações gráficas, comumente é dado destaque aos blocos que representam os componentes. No entanto, na perspectiva de Hohpe, esses diagramas devem ser projetados com foco nas funcionalidades e nas relações entre esses componentes, por meio de linhas e setas, a fim de ressaltar a comunicação entre os elementos que compõem o sistema em diferentes níveis. Essa abordagem contribui para uma compreensão mais clara e eficiente da arquitetura do software e de sua dinâmica.
Finalmente, ao adotar um conjunto de tecnologias provenientes de um fornecedor, é crucial questionar os limites de cada ferramenta e como elas se relacionam com o sistema como um todo. Dessa forma, é possível estabelecer as fronteiras da solução proposta e garantir uma abordagem mais eficiente para a arquitetura de software.
Considerações
A dificuldade em definir precisamente a arquitetura de software decorre da tentativa de associá-la diretamente aos componentes mais fundamentais do software, como dados e código. Embora temas como arquitetura em camadas, padrões de projeto e design de código-fonte estejam relacionados à arquitetura de software, essa associação é apenas parcialmente verdadeira. Como observado, as estratégias formadas pelo contexto em que o arquiteto de software está inserido são indissociáveis dos princípios que norteiam o design, a implementação e a evolução desses sistemas.
É fundamental estabelecer limites, responsabilidades e relacionamentos de cada componente selecionado para compor o mapa da arquitetura, levando em consideração todas as restrições impostas pelo ambiente e pelo objeto observado, cuja representação sistêmica será construída. Dessa forma, a arquitetura de software vai além dos componentes básicos e abrange aspectos mais amplos e complexos, que envolvem as decisões e estratégias específicas para cada contexto e projeto.
Lista de referências
- What is your definition of software architecture? – Carnegie Mellon University
- Who Needs an Architect? – Martin Fowler
- Frequency Reduces Difficulty – Martin Fowler
- C4 Model – Simon Brown