A arquitetura de software desempenha um papel crucial no desenvolvimento de sistemas. É um conjunto de decisões e estruturas que definem a organização, o design e o comportamento de um software. Neste artigo, vamos explorar os principais conceitos relacionados à arquitetura de software e explorar boas práticas na criação de uma arquitetura sólida. Sergio Gama, CTO no GFT Group, compartilha suas experiências sobre o assunto.
O que é arquitetura de software?
A arquitetura é uma atividade central do TI, que assim como na engenharia civil desempenha um papel crucial ao converter a necessidade de negócio em uma solução concreta. O arquiteto, seja no contexto da construção civil ou em projetos de TI, é responsável por estruturar e desenhar soluções que atendam as necessidades de negócio.
A arquitetura de software é a forma como os componentes do sistema se relacionam, interagem e se comportam. Abrange aspectos como a divisão em módulos, a comunicação entre os componentes, os padrões de projeto utilizados e as tecnologias adotadas.
“Arquitetura é o trabalho executado no entendimento de negócio, de maneira a estruturar e criar uma infraestrutura, um fundamento para o desenvolvimento de uma solução. Então o arquiteto, o papel fundamental dele é entender os requisitos, a necessidade, e vai estabelecer, vai desenhar e vai criar esse desenho de arquitetura, quais são os componentes necessários para atender aquele requisito.” – Sergio Gama, CTO no GFT Group
Com uma solução em mãos, passamos para a arquitetura de sistemas. Esta etapa envolve a identificação dos tipos de tecnologias que serão utilizadas. Uma parte significativa desta etapa é “olhar na prateleira”, que significa avaliar e usar as soluções existentes antes de considerar a construção de algo do zero.
Qual o papel do Arquiteto de Software?
O Arquiteto de Software precisa tomar decisões de alto nível que definem a estrutura global do sistema e orientam a equipe de desenvolvimento. Eles devem possuir habilidades técnicas sólidas, conhecimento em padrões de projeto e capacidade de equilibrar as necessidades funcionais e não funcionais para criar uma arquitetura eficiente e robusta.
Essa responsabilidade é aplicável a qualquer contexto, seja na arquitetura tradicional ou na de sistemas. O objetivo é compreender as necessidades e criar uma solução que as atenda, o que envolve entender as exigências de negócio e projetar o tipo de arquitetura adequada, identificando os componentes necessários para satisfazer essas necessidades.
“O arquiteto (…) é quem olha para o requisito, olhando a questão de negócio, a preocupação é atender o negócio, com aquela solução que vai ser proposta, o engenheiro é o responsável para materializar. É o pessoal que vai programar, que vai desenvolver, que vai criar aquele produto que é a entrega final ali desse trabalho.” – Gama
Qual o papel da Engenharia de Software?
Paralelamente, temos o papel do engenheiro, que é semelhante em ambas as áreas – construção civil e tecnologia da informação. O engenheiro civil é quem materializa o desenho da arquitetura, testa materiais e constrói a solução baseada no desenho feito pelo arquiteto. Enquanto no contexto da TI, o engenheiro de sistemas é responsável por transformar a arquitetura desenhada em um produto tangível.
É responsável por implementar os componentes do sistema, escrever o código fonte, realizar testes e garantir que o software atenda às condições estabelecidas. Este profissional deve ter um bom entendimento da proposta e trabalhar em estreita colaboração com o arquiteto para garantir uma implementação eficaz.
Gama complementa: “O engenheiro, é quem vai construir, quem vai definir, testar materiais, quem vai construir baseado naquele desenho de arquitetura, então quem vai materializar aquele desenho, aquela especificação de arquitetura do que foi desenhado.”
Vale ressaltar que a transição do trabalho do arquiteto para o do engenheiro não é uma “passagem de bastão”. Na verdade, o arquiteto permanece envolvido durante todo o processo, desde a definição das exigências até a conclusão do projeto de software. Afinal, a principal preocupação é garantir que a solução proposta atenda às necessidades do negócio.
Qual o papel da equipe de desenvolvimento?
A tarefa de programar e desenvolver o produto final recai sobre a equipe de desenvolvimento. Estes são os encarregados de transformar as especificações do projeto em um produto concreto e utilizável.
A equipe de desenvolvimento é composta por arquitetos, engenheiros de software, testadores e outros profissionais envolvidos no processo de criação do software. Cada membro da equipe tem um papel específico, mas todos devem trabalhar em conjunto para garantir o sucesso do projeto. A equipe de desenvolvimento é responsável por implementar a arquitetura, realizar testes de qualidade, solucionar problemas e entregar um produto final de alta qualidade.
Qual a diferença entre arquitetura de software e hardware?
A arquitetura hardware e a de software são dois conceitos distintos. A arquitetura de hardware refere-se à organização física dos componentes eletrônicos de um sistema, como processadores, memória, dispositivos de armazenamento e periféricos.
Por outro lado, a arquitetura de software lida com a estrutura lógica e organizacional do software, incluindo os componentes, as interfaces, os padrões de comunicação e a distribuição dos serviços.
“Existe uma diferença básica que é, eu tô trabalhando com algo lógico, que vai rodar sobre um software, ou sobre hardware, então o arquiteto de hardware, ele trabalha com alguma coisa mais física, então ele tá olhando placa, conectores, integrações, os cabos, como é que vai funcionar a CPU, placa controladora, ele tem que ter os mesmos fundamentos de arquitetura, porque ele precisa entender o requisito.” – Sergio Gama
Cada um tem um conjunto específico de responsabilidades, mas compartilham fundamentos comuns: entender as exigências, o propósito, a adaptabilidade e o público-alvo.
Boas práticas na criação de uma arquitetura de software
Os profissionais que lidam com arquitetura de software devem conhecer e entender as tendências para manter a competitividade em um mercado que está sempre em evolução. Assim, é possível garantir que a arquitetura corporativa de uma organização continue relevante e alinhada com os objetivos de negócio.
Veja a seguir algumas práticas recomendadas para criar uma arquitetura eficiente:
Planos Diretores de Tecnologia da Informação (PDTIs)
Planos Diretores de Tecnologia da Informação (PDTIs) são documentos estratégicos que orientam o desenvolvimento e a TI em uma organização. Eles incluem diretrizes para a arquitetura de software, estabelecendo padrões e políticas a serem seguidos. Os PDTIs são importantes para alinhar as iniciativas de tecnologia com os objetivos de negócio e garantir a eficiência e a integração dos sistemas de software.
Esses planos oferecem um direcionamento para as decisões tecnológicas, indicando aonde se quer chegar e quais definições arquitetônicas devem ser adotadas. Assim, pode-se pensar na arquitetura corporativa como um mapa para a tomada de decisões em TI.
Apesar das variações terminológicas entre arquitetura de aplicações e de soluções, o principal para os executivos de TI é ter um plano estratégico bem estabelecido que define os direcionadores de arquitetura. Este é um componente crucial para a tomada de decisões informadas e estratégicas na área de TI.
Mapeamento dos componentes da arquitetura
Uma arquitetura corporativa vai além do simples desenho de sistemas e aplicações, pois aborda as necessidades de negócios da organização. Ela observa as capacidades de negócio e os produtos e, a partir disso, estabelece os projetos necessários.
Dentre os tipos de arquiteturas encontram-se as de nuvem, infraestrutura, segurança, entre outras. Assim, uma arquitetura corporativa bem definida oferece orientação para as equipes de desenvolvimento e ajuda a conduzir o andamento de soluções ou aplicações.
Business composable architecture
Agora, se quisermos ir além, algumas tendências emergentes em arquitetura de negócios incluem a “business composable architecture”, um conceito trazido pelo Gartner que se baseia na capacidade de uma organização de alinhar rapidamente seus recursos tecnológicos para atender a novas necessidades de negócios.
Embora haja muito foco na arquitetura de microsserviços, um dos padrões preferidos dos desenvolvedores e arquitetos de software, é preciso entender que as empresas como um todo não funcionam dessa maneira. Portanto, é necessário criar um equilíbrio entre as necessidades específicas de negócios e os avanços tecnológicos.
Minimum Viable Architecture
Outra tendência interessante é a da “Minimum Viable Architecture” (MVA), que propõe um desenvolvimento iterativo da arquitetura, permitindo aprendizado e adaptação contínuos. A ideia é criar e, em seguida, “produtizar” a arquitetura, ou seja, torná-la reutilizável para diferentes frentes ou squads de desenvolvimento. Essa abordagem permite a reutilização eficiente de componentes de arquitetura e oferece uma maneira mais ágil de se adaptar a mudanças.
Entrevistas
Entrevistas e discussões com stakeholders são ferramentas essenciais no desenvolvimento de arquiteturas de soluções. Compreender a cultura organizacional e as necessidades do cliente são partes fundamentais desse processo.
Administrar adequadamente o ciclo de entrevistas, revisitar conceitos e ideias, e ajustar continuamente a proposta são práticas importantes. A compreensão correta das necessidades do cliente é o cerne de uma solução arquitetural bem-sucedida. Isso envolve fazer as perguntas certas e evitar a aceitação passiva de soluções pré-definidas.
Políticas de Governança
Governança é fundamental para gerenciar ativos e evitar problemas futuros, como o débito tecnológico. Na criação de um ambiente de desenvolvimento na nuvem é importante considerar políticas de segurança e permissões para diferentes ambientes.
Squads de desenvolvimento desempenham papéis e responsabilidades cruciais. Embora o mundo ideal seja ter processos detalhados e organizados, na prática, isso nem sempre acontece. Reconhecer essa diferença é o primeiro passo para a melhoria contínua na arquitetura de software.
Padrões de Arquitetura
Em meio à era da transformação digital, o desenvolvimento de um software robusto e eficiente se tornou um tema essencial para líderes de TI. Com a possibilidade de combinar diferentes padrões arquiteturais, como hexagonal, layers (camadas), event-driven (baseado em eventos) e microsserviços, a escolha correta se baseia na necessidade do negócio e na capacidade de oferecer soluções escaláveis e eficientes.
Cada padrão possui seus próprios benefícios e desafios, mas todos têm como objetivo facilitar a criação de sistemas capazes de atender às demandas de um mundo digital cada vez mais complexo e interconectado.
Hexagonal
Também conhecida como Portas e Adaptadores, é um padrão de design de software que visa a separação de preocupações para facilitar a manutenção e a escalabilidade dos sistemas. Este modelo propõe a divisão do sistema em três partes: a camada interna (domínio), a camada intermediária (portas) e a camada externa (adaptadores).
A ideia central é que a camada de domínio, onde a lógica de negócio reside, não deve ter dependências diretas sobre as camadas externas, tais como bancos de dados, UI ou sistemas externos. Ao invés disso, essas comunicações são feitas através de “portas”, as quais são implementadas pelos “adaptadores”.
Assim, a arquitetura hexagonal permite a troca de componentes da camada externa sem afetar o núcleo da aplicação, proporcionando flexibilidade e facilitando a implementação de testes.
Baseada em layers
A arquitetura Baseada em Camadas, ou Layered Architecture, é um padrão de design de software que subdivide a aplicação em grupos (camadas) de responsabilidade semelhante.
Geralmente, uma aplicação de software padrão é dividida em três ou quatro camadas: a camada de apresentação, que é responsável pela interação com o usuário; a camada de negócios, que contém toda a lógica de negócio da aplicação; a camada de persistência, que lida com a armazenagem e recuperação de dados; e opcionalmente a camada de infraestrutura, que provê capacidades técnicas genéricas.
O principal objetivo dessa arquitetura é a separação de preocupações, onde cada camada se preocupa apenas com uma específica função da aplicação. Isso proporciona uma maior flexibilidade e torna a aplicação mais fácil de manter, pois mudanças em uma camada não necessariamente afetam as outras.
Event-driven
A Arquitetura Orientada a Eventos, ou Event-Driven Architecture (EDA), é um padrão de design de software onde a execução da lógica é determinada por eventos específicos, como cliques de usuário, atualizações de dados ou mensagens de outros programas.
Esses eventos são detectados por componentes de software chamados de listeners ou observadores, que desencadeiam ações apropriadas em resposta. Diferente de outras arquiteturas que seguem uma sequência previsível e linear, a EDA é altamente descentralizada e assíncrona. Isso a torna ideal para cenários onde há grande volume de dados e interações, como em aplicações em tempo real, Internet das Coisas (IoT), e microsserviços.
Além disso, a EDA pode melhorar a escalabilidade e a resiliência do sistema, já que os componentes podem ser adicionados, removidos ou modificados sem interromper a operação do todo.
Microsserviços e API
Por último, a arquitetura de microsserviços tem ganhado popularidade pela sua capacidade de permitir o desenvolvimento, a implantação e a escala de serviços de maneira independente.
Hoje, a arquitetura baseada em microsserviços e APIs tem assumido uma função crítica na transformação digital de empresas. Além de favorecer a modularidade e a escalabilidade, ela permite a criação de ecossistemas digitais, através do qual as empresas podem vender seus serviços. Um exemplo disso é a tendência do ‘banking as a service’, onde bancos vendem serviços como análise de crédito e abertura de contas como serviços independentes.
Para se aprofundar no assunto, convidamos você a baixar nosso material de apoio do podcast!
Erros comuns na arquitetura de software
No mundo real, a arquitetura de sistemas está longe de ser um processo tranquilo e sem falhas. Ao olharmos para a experiência de um profissional da indústria, fica evidente que erros e desafios são comuns, mas eles não devem ser vistos como fracassos. Em vez disso, eles são oportunidades de aprendizado e crescimento.
1- Falta de distinção de papéis
É comum na prática enfrentarmos desafios relacionados à distinção desses papéis. Muitas vezes, o desenvolvedor assume o papel do arquiteto ou do engenheiro. Em outros casos, o arquiteto acaba se envolvendo no desenvolvimento do código, uma atividade que deve ser da alçada do engenheiro. Isso ocorre até mesmo em grandes empresas e pode levar à diluição das responsabilidades e confusões de papéis.
Portanto, é crucial que os papéis e responsabilidades estejam bem definidos e sejam respeitados, a fim de garantir o sucesso de um projeto. O ideal é que o arquiteto foque em seus deveres, o engenheiro em sua função e o desenvolvedor em suas responsabilidades, garantindo que cada membro da equipe contribua com sua expertise única para a entrega do produto final. Assim, é possível evitar conflitos de papéis e garantir uma execução eficiente e eficaz do projeto.
Gama complementa: “Acaba que o desenvolvedor virou arquiteto, o engenheiro é o desenvolvedor, e aí mudou, então muda os papéis pra caramba, mas a ideia, se a gente for pensar em algo que seria mais interessante a se ter como time, é o teu arquiteto com papel super definido. A gente sabe que mesmo em empresas grandes o arquiteto acaba mexendo em código, que deveria ser engenharia, ele acaba se envolvendo.”
2- Falta de planejamento arquitetônico
Dentro da arquitetura de um grande sistema, como o YouTube, por exemplo, existem dois elementos principais: tempo e dinheiro. A implementação de uma arquitetura semelhante em qualquer sistema nem sempre é viável ou necessária, da mesma forma que nem sempre precisamos do carro mais rápido para todas as situações. A ideia é adequar a arquitetura à necessidade, levando em conta os recursos disponíveis.
3- Excesso de ajustes durante o desenvolvimento
Ajustes e “puxadinhos” são normais no desenvolvimento de projetos de arquitetura de sistemas. Isso pode ocorrer devido a mudanças nas exigências do projeto ou a desafios inesperados. Durante a pandemia, por exemplo, muitas empresas se viram precisando se digitalizar da noite para o dia, criando novos e-commerces e outras soluções digitais. Em situações como essa, os ajustes são inevitáveis.
É essencial entender que a avaliação do trabalho de um arquiteto de sistemas deve levar em conta as circunstâncias e exigências de cada projeto. Críticas após a implementação podem ser injustas se não considerarem o contexto em que a solução foi desenvolvida. Monitoramento e ajustes são componentes integrais do processo, pois a perfeição raramente é alcançada na primeira tentativa.
4- Falta de padrões arquitetônicos
Os padrões devem ser vistos como direcionadores, melhores práticas que podem nortear o processo de desenvolvimento, e não como regras fixas a serem seguidas à risca. É importante frisar que não há uma “receita de bolo” quando se trata de padrões arquitetônicos. Cada projeto tem suas especificidades e demandas próprias que requerem uma abordagem personalizada.
5- Foco na solução e não no problema
Balancear inovação e tecnologia com as necessidades reais do negócio é vital. Mas é preciso cautela para evitar confusões comuns. A essência dessa transformação não se resume a ser disruptiva, mas sim em servir o negócio de maneira eficaz. A tecnologia é um meio para esse fim, não o produto final.
As empresas não compram tecnologia, elas compram soluções. Isso evidencia a importância de focar na resolução de problemas de negócios, em vez de meramente adotar a tecnologia mais recente. Esse foco no problema em vez da ferramenta é essencial para o sucesso de qualquer transformação digital.
Nesse contexto, é preciso ter cuidado com as tendências e hypes no mundo da tecnologia. A escolha da tecnologia deve levar em consideração critérios como escalabilidade, custo-benefício e viabilidade de evolução. Focar demais no que é novo e empolgante pode levar à adoção de tecnologias que, embora impressionantes, podem não atender adequadamente às necessidades do negócio.
6- Falta de entendimento constante do negócio com o cliente
Quando se pensa em construir um novo projeto de software, a primeira e mais crucial etapa é entender o negócio. Este entendimento não é uma atividade única, mas um processo cíclico que inclui a identificação das partes do negócio e a criação de uma “arquitetura intencional”.
Isso serve como um plano inicial que deve ser validado com o cliente. Esse processo iterativo enfatiza a importância do engajamento contínuo com o cliente ao longo de todo o processo de desenvolvimento da solução.
Por fim, é preciso lembrar que, embora a tecnologia seja uma ferramenta essencial, ela entra no final do processo de desenvolvimento de uma solução. A tecnologia é uma peça do quebra-cabeça, não o quadro completo.
Conclusão
Em resumo, a arquitetura de software é um elemento fundamental no desenvolvimento de sistemas, pois define a organização, o design e o comportamento de um software. O papel do arquiteto de software é estruturar e criar uma infraestrutura para atender às necessidades do negócio, enquanto o engenheiro de software é responsável por materializar essa arquitetura e construir o produto final. É importante estabelecer papéis e responsabilidades claras para garantir uma execução eficiente do projeto.
Assine nossa Newsletter para receber os melhores conteúdos do Itshow em sua caixa de entrada.
