O que é arquitetura de software?

O processo de arquitetura de software considera os requisitos do cliente, os analisa e produz um projeto de componente de software que atenderá às necessidades dele. Os projetos de software bem-sucedidos devem equilibrar as compensações inevitáveis que surgem devido a requisitos conflitantes, estar em conformidade com os princípios de design e técnicas de prática recomendada que se desenvolveram com o tempo e complementar os modernos sistemas de hardware, rede e gerenciamento. Uma arquitetura de software sólida envolve uma considerável experiência teórica e prática, bem como a visão necessária para transformar o que pode parecer requisitos e cenários comerciais vagos em projetos de trabalho sólidos e práticos.

A arquitetura de software envolve definir uma solução estruturada que atenda a todos os requisitos técnicos e operacionais e que, ao mesmo tempo, otimize atributos de qualidade comuns, como desempenho, segurança e capacidade de gerenciamento. Ela implica uma série de decisões baseadas em inúmeros fatores, e cada uma dessas decisões pode ter impacto considerável sobre a qualidade, o desempenho, a facilidade de manutenção e o sucesso geral do software.

O software moderno raramente é autônomo. No mínimo, na maioria dos casos, ele irá interagir com uma fonte de dados, como um banco de dados corporativo, que expõe informações com as quais os usuários do software trabalham. Normalmente o software moderno também deve interagir com outros serviços e funções de rede para executar autenticação, obter e publicar informações e propiciar uma experiência integrada para o usuário. Sem uma arquitetura adequada, pode ser difícil ou até mesmo impossível implantar, operar, manter e integrar o software a outros sistemas corretamente, além de não atender às necessidades do usuário.

A arquitetura de software pode ser considerada como um mapeamento entre o que um componente de software deve realizar e os detalhes da implementação como código. Desenvolver a arquitetura certa assegurará a combinação ideal entre requisitos e resultados. Um software bem-arquitetado executará as tarefas especificadas seguindo os parâmetros dos requisitos originais e fará isso de um modo que maximize o desempenho, a segurança, a confiabilidade e muitos outros fatores.

No nível mais alto, o projeto de arquitetura deve expor a estrutura do sistema e ocultar os detalhes da implementação, realizar todos os casos de uso e cenários, tentar considerar os requisitos de todas as partes interessadas e atender o máximo possível a todos os requisitos funcionais e de qualidade.

Por que a arquitetura de software é importante?

Os requisitos do software moderno estão cada vez mais complexos, uma vez que os usuários esperam mais de seus aplicativos. Aplicativos de área de trabalho autônomos simples não mais são bons o suficiente na maior parte dos cenários comerciais e de negócios. Em nosso mundo conectado, o aplicativo deve interagir com outros aplicativos e com serviços e ser executado em vários ambientes, como a nuvem e os dispositivos portáteis. Os projetos monolíticos comuns no passado foram substituídos por software orientado por serviços dividido em componentes que usa estruturas, sistemas operacionais, hosts de tempo de execução e redes para implementar recursos que poucos anos atrás eram desconhecidos.

Essa complexidade afeta não somente o projeto, mas também a implantação, a manutenção e a administração do software. Agora o custo total de propriedade (TCO) do software é formato predominantemente pelos custos pós-implantação. Um aplicativo bem-arquitetado minimizará o TCO reduzindo o custo e o tempo necessários para implantar o aplicativo, mantê-lo funcionando, atualizá-lo conforme as mudanças nos requisitos e corrigir problemas. Ele também simplificará a administração e o suporte ao usuário.

O software também deve cumprir diversos critérios vitais para ser bem-sucedido. Ele deve oferecer segurança para que o aplicativo e seus dados fiquem protegidos contra ataques mal-intencionados e erros acidentais. Ele deve ser robusto e confiável para minimizar falhas e os custos associados. Ele deve ser executado dentro dos parâmetros exigidos para atender às necessidades do cliente, como tempo de resposta máximo ou uma determinada capacidade de carga de trabalho. Ele deve ser passível de manutenção a fim de minimizar os custos de administração e suporte e extensível o suficiente para possibilitar as alterações e atualizações inevitáveis que serão necessárias com o passar do tempo.

Todos esses fatores envolvem algumas compensações. Por exemplo, a implementação dos mecanismos mais seguros por meio de criptografia complexa afetará o desempenho. Implementar opções de atualização e configuração variadas pode complicar ainda mais a implantação e a administração. Além disso, quanto mais complexo o projeto, mais cara será a implementação. Uma boa arquitetura terá como objetivo equilibrar esses fatores para gerar o melhor resultado para um cenário específico.

O que um arquiteto de software faz?

A arquitetura de software começa com um conjunto de requisitos. Eles podem ser expressos na forma de diagramas, fluxogramas de processo, modelos ou listas documentadas de tarefas operacionais que o software deve executar. Normalmente o cliente ou parceiro também externará requisitos menos precisos, como a aparência ou o modo como certas interfaces de usuário devem funcionar para tarefas comuns. Os requisitos também devem incluir informações sobre o software, os sistemas, o hardware e as redes existentes com os quais o novo software fará interface, além de outros fatores, como o plano de implantação e manutenção e, claro, o orçamento disponível para o projeto.

O arquiteto de software deve levar em consideração as necessidades do cliente. No entanto, o termo geral “cliente” normalmente abrange três áreas de responsabilidade conflitantes: os requisitos comerciais, os requisitos do usuário e os requisitos de sistemas. Os requisitos comerciais geralmente definem uma série de fatores, como os processos de negócios, os fatores de desempenho (segurança, confiabilidade e taxa de transferência) e as restrições orçamentárias e de custo. Os requisitos do usuário incluem o design de interface, os recursos operacionais e a facilidade de uso do software. Os requisitos de sistema incluem os recursos e restrições de hardware, de rede e do ambiente de tempo de execução. A Figura 1 mostra a variação desses diferentes requisitos, por isso o arquiteto deve trabalhar para chegar a um design que se encaixe na área de sobreposição.

Figura 1 – Os requisitos conflitantes de um cliente típico

Os arquitetos de software têm uma metodologia própria para coletar e analisar os requisitos e definir a arquitetura. Porém, entre as perguntas que eles têm de responder com frequência estão as seguintes: "como os usuários trabalharão com o aplicativo?", "como o aplicativo será implantado em produção e gerenciado?", "quais são os requisitos de atributo de qualidade do aplicativo, como segurança, desempenho, simultaneidade, internacionalização e configuração?", "como projetar o aplicativo para que seja flexível e passível de manutenção com o tempo?" e "quais são as tendências arquitetônicas que podem afetar o aplicativo agora ou depois que ele for implantado?"

Essa última pergunta é ao mesmo tempo interessante e importante. Um bom projeto de software atende aos requisitos do cliente agora, mas continuará a fazê-lo no futuro próximo. Isso afeta as decisões que o arquiteto deve tomar sobre hardware, componentes, estruturas, plataformas de tempo de execução, sistemas de gerenciamento de software e muitos outros recursos incorporados ao software ou com os quais ele deve se integrar.

Assim como a maioria das tarefas no mundo do projeto e do desenvolvimento de software, projetar a arquitetura é um processo antecipado e iterativo. Muitas tarefas iniciais, como análise de requisitos, pesquisa técnica e identificação de objetivos, normalmente ocorrem no início do processo. A próxima etapa é identificar os principais cenários para o projeto. Esses são os requisitos principais que o software deve atender e as restrições dentre as quais ele deve operar. Com base nessas informações, o arquiteto pode criar uma visão geral do aplicativo. Essa visão geral inclui detalhes de alto nível, como o tipo de aplicativo (web, telefone, área de trabalho ou nuvem), a arquitetura de implantação (geralmente um projeto em camadas com os componentes se comunicando por limites de hardware e rede), os estilos de arquitetura apropriados a serem seguidos (n camadas, cliente-servidor ou orientação por serviços) e as tecnologias de implementação mais adequadas ao cenário.

A partir daí, o arquiteto pode começar a gerar projetos candidatos que atendam aos requisitos mais importantes e de alto nível identificados anteriormente. Esse projeto é então revisado e testado nos cenários-chave, muitas vezes junto com os comentários do cliente e as versões de avaliação ou teste, para assegurar que ofereça a solução ideal. É pouco provável que isso ocorra durante a primeira iteração, mas à medida que o ciclo se repetir o projeto convergirá para os requisitos e cenários-chave. A Figura 2 mostra essa abordagem iterativa.

Figura 2 – Um processo de projeto arquitetônico iterativo

À medida que o design se torna mais granular e as tarefas e componentes específicos são identificados, a cada etapa o arquiteto pode aperfeiçoar ainda mais e adicionar detalhes. Por exemplo, depois de identificar o estilo arquitetônico e a abordagem de implantação, o arquiteto pode tomar decisões sobre a comunicação entre camadas e componentes. Isso pode envolver a escolha de um protocolo com base nos requisitos atuais e futuros e a consideração de visualizações da nova tecnologia e dos novos recursos definidos em padrões futuros.

O produto final do trabalho de um arquiteto normalmente é um conjunto de esquemas, modelos e documentos que definem o aplicativo de várias perspectivas para que, quando combinados, ofereçam aos desenvolvedores, às equipes de teste, aos administradores e à gerência todas as informações necessárias para implementar o projeto. Essas informações descreverão a estrutura e o layout dos componentes e das camadas do aplicativo, de que maneira questões abrangente (como registro em log e validação), são tratadas, o plano de testes e implantação e a documentação que auxiliará os desenvolvedores e administradores e a equipe de suporte.

O projeto final também deve especificar os atributos de qualidade que o aplicativo deve atender. Eles são o resultado das decisões consideradas e compensações feitas pelo arquiteto após consulta ao cliente. Eles incluem definições dos requisitos de segurança e do plano de implementação de segurança, a escalabilidade e o desempenho necessários quando o software é implantado na plataforma de destino, como a facilidade de manutenção e a extensibilidade são implementadas e os recursos que possibilitam a interoperabilidade com outros sistemas.

Quais são as habilidades que um arquiteto de software deve ter?

É evidente que um arquiteto de software precisa ter muitas habilidades tanto pessoais quanto técnicas. Durante as etapas de análise de requisitos e revisão, o arquiteto deve trabalhar com o cliente, consultar parceiros e outros membros da equipe e agir como intermediário entre gerentes, usuários e administradores de sistema. Sobressair-se nessas habilidades pessoais pode gerar um plano inicial melhor e um conjunto de requisitos mais preciso, o que mais tarde se traduzirá em ganhos de tempo e esforço.

Um arquiteto de software também deve ter as habilidades técnicas necessárias para compreender como os modernos sistemas de software, estruturas e hardware dão suporte aos requisitos, de que modo os fatores de sistema operacional e rede podem afetar as decisões sobre o projeto e como as tendências e mudanças nessas áreas afetarão o projeto. Após a análise inicial dos requisitos, um arquiteto de software também deve aplicar as habilidades técnicas referentes a padrões de projeto, padrões de mensagens e comunicação, recursos de código, questões de segurança e restrições de desempenho. Tudo isso exige um profundo conhecimento das tecnologias que serão usadas para implementar o software final.

É óbvio que a arquitetura de software também requer visão. Poder enxergar como os sistemas se encaixarão para interoperar, como eles serão particionados e implantados e como interagem com usuários muitas vezes são questões que só podem ser respondidas se o arquiteto puder ter em mente a solução como um todo. Isso requer uma abordagem organizada e muita atenção aos detalhes para verificar e compreender todos os requisitos e restrições e gradualmente transformá-los em um projeto técnico fluente e completo. No entanto, também é preciso ter talento e imaginação para visualizar o resultado final e trabalhar metodicamente para chegar à solução perfeita.