Arquitetura de Soluções: papel do arquiteto e pensamento sistêmico

Comunicação e Decisão Arquitetural - Clareza quanto ao problema

Apresentando o desafio na Amaral Seguros

Olá a todas as pessoas. Retomando nossa jornada de transição de Dev (pessoa desenvolvedora) para pessoa arquiteta de soluções, vamos continuar e começar a entender quais foram os desafios que a liderança da Amaral Seguros propôs à Ana para avaliar sua capacidade de atuar como pessoa arquiteta de soluções. Vamos?

Recordando: ela recebeu algumas missões, e a primeira está relacionada à plataforma de comércio eletrônico da Amaral Seguros. Parece que há desafios importantes ali. Essa plataforma cresceu de forma orgânica. A equipe de engenharia, apesar de muito talentosa, ainda enfrenta problemas para publicar novas funcionalidades, que estão levando cada vez mais tempo para serem disponibilizadas em produção. Além disso, o custo de manutenção tem aumentado. Foi atribuído à Ana conversar com as áreas de negócio para entender quais são os problemas e elaborar uma proposta de solução.

Vamos entender o que a área explicou e compartilhou com Ana. Foram identificados alguns problemas, e Ana registrou três principais: as vendas estão sendo afetadas, a imagem da empresa está sendo prejudicada e as pessoas clientes estão insatisfeitas. Esses foram os pontos levantados.

Propondo uma solução técnica e enfrentando resistência

Diante disso, o primeiro instinto de Ana foi aprofundar a compreensão do problema. Ela sabe que muitos elementos em código legado oferecem oportunidade de refatoração e de melhoria na base de código, que código de baixa qualidade gera lentidão e que erros podem estar afetando a experiência das pessoas clientes da Amaral Seguros no comércio eletrônico. Essa foi a primeira hipótese que lhe ocorreu.

Com base nisso, ela traçou uma estratégia e desenhou uma proposta de solução fundamentada no que conhecia, em sua zona de conforto e especialidade: desenvolvimento de software. Em seguida, convocou uma reunião com as áreas de negócio.

O que aconteceu? Ana apresentou sua proposta, muito baseada em refatoração e na troca de frameworks (estruturas de desenvolvimento), e as pessoas das áreas de negócio não compreenderam. A gerência da área comercial chegou a pedir que alguém traduzisse o que ela estava dizendo, pois não estava entendendo. Quando Ana começou a falar sobre frameworks (estruturas de desenvolvimento), refatoração de código e boas práticas de SOLID (princípios de design orientado a objetos), nada disso fez sentido para as áreas de negócio.

Houve ainda outro agravante. O fornecedor da plataforma de comércio eletrônico questionou a visão que Ana tinha sobre as integrações, o funcionamento da solução e como ela havia chegado à conclusão de que a refatoração de código era o caminho para resolver o problema.

Desenvolvendo o pensamento arquitetural e questionando o problema

Essa é uma situação comum. Quando migramos do desenvolvimento de software para a arquitetura de soluções, tentar fundamentar as propostas totalmente no lado técnico — no código — pode não funcionar. O aspecto técnico é importante, mas não necessariamente o código em si. Além disso, o uso de termos técnicos diante das áreas de negócio costuma gerar ruído.

O que Ana precisa desenvolver aqui é o pensamento arquitetural. Quais foram as três principais falhas que Ana cometeu nesse primeiro enfoque? Ela supôs que tinha entendido o problema.

As pessoas relataram quais eram os problemas e ela supôs que havia entendido, com base nesse relato inicial, qual era o problema. Apoiada nessa suposição, propôs uma solução que, em sua opinião, era o melhor caminho a seguir. Partiu de algumas hipóteses, assumindo certas coisas como verdades a partir dos problemas inicialmente reportados. Por fim, não conseguiu se comunicar de forma eficiente com as áreas de negócio. As pessoas não compreenderam o que ela estava propondo. Talvez resolvesse, muito provavelmente não, mas o fato é que a mensagem não ficou clara. As pessoas não conseguiram entender o que ela estava transmitindo.

O ponto central é que, sempre que identificarmos um problema de negócio, nós precisamos aprofundar a análise: investigar quais são os pontos, quais são as consequências desse problema e como ele impacta o negócio de fato. Neste caso, o negócio da Amaral Seguros, uma empresa do setor de seguros. Por que as vendas estão sendo afetadas? Por que a imagem da empresa está sendo prejudicada? Por que as pessoas clientes estão insatisfeitas? “Por quê” é uma expressão fundamental que pode abrir muitas portas relacionadas à clareza de entendimento e apoiar a proposição de soluções.

Mapeando causas e impactos com as áreas de negócio

Ana entendeu que havia cometido um erro no enfoque inicial e, sendo brasileira, não desistiu. Passou a analisar o problema sob uma nova ótica. A primeira estratégia foi conversar com pessoas das áreas de negócio para entender os detalhes dos problemas apontados. Do ponto de vista de cada pessoa, qual era o problema, qual era a particularidade e quais eram os detalhes daqueles problemas inicialmente identificados. Isso foi uma atitude muito inteligente. Após essas conversas, a visão ficou muito mais clara.

Revisando o que foi mapeado, temos:

• As vendas estão sendo afetadas porque o tempo de resposta da tela de cobrança é muito longo e apresenta falhas, o que leva pessoas clientes a desistirem.
• A imagem da empresa está sendo prejudicada porque, quando se consegue concluir a contratação, o sistema fica travado por bastante tempo. A pessoa cliente conclui a contratação, o sistema fica preso em uma tela de loading e não oferece visibilidade sobre a aceitação do pagamento, o que tem gerado incômodo.
• As pessoas clientes estão insatisfeitas pelos problemas 1 e 2 e também por mais um fator: quem consegue contratar não encontra uma forma simples de acessar as informações do produto contratado. No momento de acionar o seguro, não há visibilidade sobre coberturas, assistências e outros detalhes.

A experiência de pós-venda é bastante ruim, ainda que a experiência de pré-venda seja mais crítica.

Concluindo com próximos passos e mensagem-chave

No próximo vídeo, exploraremos o que Ana fez após alcançar uma visão clara do problema e deixaremos uma mensagem importante. Nós podemos ter dúvidas quanto à solução a ser adotada, mas, como pessoas que desenham soluções, não podemos ter dúvidas sobre qual é o problema. Enquanto houver dúvidas, precisamos conversar com as pessoas e entender até alcançar clareza absoluta sobre qual problema será resolvido; só então ponderamos as alternativas de solução.

Isso é tudo. Até o próximo vídeo, pessoal! [♪]

Comunicação e Decisão Arquitetural - Uma nova proposta de solução

Apresentando os problemas de negócio

Muito bem, pessoal. Vamos continuar. Ana já tem uma visão clara sobre a perspectiva de negócio, de qual é o problema e quais são as consequências desses problemas. Ela mapeou três problemas importantes, sendo dois mais críticos que estão impactando os lucros. O cliente não consegue comprar. Quando compra, não sabe se o pagamento foi realizado ou não. E também existe outro problema, que é a clareza sobre os detalhes do produto. Esse terceiro problema não é tão crítico quanto os dois primeiros. Primeiro, precisamos focar. E esse ponto de poder priorizar e negociar a priorização com as áreas de negócio é outra responsabilidade muito importante da pessoa que projeta as soluções. Geralmente, as áreas vão querer tudo o mais rápido possível e com a maior perfeição possível para resolver todos os problemas. Não é possível fazer tudo. Então, precisamos ter habilidade de negociação.

Temos vários problemas aqui. Os primeiros estão afetando a compra. Se a pessoa nem sequer consegue efetuar a compra, não terá o terceiro problema, que está relacionado a identificar detalhes do produto, detalhes do produto contratado. Também é importante, mas vamos priorizar o que é mais crítico, o que está impedindo que o cliente faça a compra. Tudo claro? Perfeito!

Investigando a arquitetura atual

Um ponto importante. Ana começou a investigar mais, conversar com as equipes que se ocupavam do sistema, com o fornecedor que gerencia a plataforma de e-commerce, e ela identificou um problema em sua visão inicial. A visão, o panorama inicial de arquitetura que ela havia identificado era que o usuário se comunicava com a plataforma de e-commerce, uma plataforma criada em Java e que possuía um banco de dados SQL, para fins de persistência. Executava as atividades, as ações solicitadas pelo usuário, e quando o usuário clicava em comprar, essa plataforma contatava o gateway de pagamentos, a plataforma que intermedia o pagamento, de acordo com a forma de pagamento selecionada pelo cliente.

Inclusive, abrimos um parêntese aqui, falando de diagramas, que é uma das principais ferramentas da pessoa que projeta soluções, é construir diagramas e mostrar, dar uma visão clara sobre o As Is (como está uma solução neste momento), o To Be (como proponho que seja construído), às vezes podemos gerar duas ou três visões de como isso pode ser feito. E ferramentas para criar esses diagramas, há várias no mercado, mencionamos algumas aqui, mencionamos duas. Scale Draw, aqui à direita, e aqui à esquerda Draw IO, que são opções gratuitas, opções web, que não precisamos instalar nada, e podemos criar nossos diagramas. Usamos muito desde há bastante tempo, acredito que desde que começamos, antes de começar a trabalhar como arquiteto de soluções, já usávamos Draw IO para a parte de engenharia de software. Genial? Vamos.

Identificando falhas no design atual

Ana mapeou, conversou, usou Draw IO e finalmente desenhou o que de fato era a peça que faltava no design da arquitetura do cenário atual, do As Is, que era o seguinte: o sistema de e-commerce não se comunicava diretamente com o gateway de pagamentos.

Quando o usuário clica em "finalizar compra" no e-commerce da Amaral Seguros, o sistema se comunica com o sistema interno, construído em .NET, que aplica uma série de regras de negócio. Em seguida, esse sistema faz a ponte com o gateway de pagamentos. Esse processo estava lento, o que resultava em uma experiência de usuário insatisfatória. Não se tratava apenas da comunicação entre o e-commerce e o gateway de pagamentos; havia toda uma série de regras de negócio sendo aplicadas, impactando negativamente na experiência do usuário final.

Propondo uma nova solução arquitetural

A proposta inicial de Ana era resolver o problema com código e refatoração. Isso poderia ser uma solução? Poderia. Seria a primeira opção a ser avaliada? Não. Estamos lidando com aplicações legadas, e reconstruir, entender e desmembrar todo um conjunto de aplicações legadas pode ser um processo muito lento e caro para uma empresa.

Após mapear o problema, Ana propôs uma solução. Com a visão de negócio e de arquitetura claras, ela se reuniu com os times técnicos responsáveis pelos sistemas e, em conjunto, desenhou um processo onde o pagamento passou a ser assíncrono. No modelo atual, o usuário clicava em "comprar", a comunicação ocorria com o sistema interno que aplicava regras de negócio ao pedido, e o cliente aguardava até que a aplicação interna contatasse o gateway de pagamentos e tudo fosse respondido. Era uma comunicação síncrona.

Implementando a comunicação assíncrona

A nova proposta de arquitetura implicou em mudar a forma como esses sistemas se comunicam. O usuário continua se comunicando com o e-commerce, de forma transparente. O e-commerce mantém uma base MySQL, mas agora publica o pedido em uma fila de mensagens e retorna ao usuário: "Estimado usuário, seu pedido foi recebido, em breve você receberá uma notificação com a confirmação da compra." Isso libera o usuário e proporciona uma experiência mais ágil.

Enquanto isso, o sistema interno criado em .NET fica escutando essa fila. Quando novos pedidos chegam, ele se comunica com o gateway de pagamentos, aplicando as regras de negócio antes disso. Quando o gateway de pagamentos devolve a resposta ao sistema interno, ela é publicada na mensageria, atualizando nosso e-commerce, que notifica o usuário por e-mail de que a compra foi confirmada. O fluxo se tornou mais complexo, mas criamos uma arquitetura desacoplada entre os componentes.

Concluindo a solução proposta

Essa é a solução para todo problema de lentidão? De forma alguma. Para um problema, podem existir várias soluções. No caso específico mapeado e na interação com os times técnicos, essa foi a melhor solução encontrada para resolver o problema.

No próximo vídeo, daremos continuidade e veremos os desenvolvimentos dessa proposta de solução que Ana elaborou em conjunto com os outros times. Obrigado a todos!

Comunicação e Decisão Arquitetural - Comunicação efetiva com as áreas de negócio

Destacando a responsabilidade da arquiteta de soluções

Mais uma vez, vamos continuar com os próximos passos deste percurso que estamos seguindo junto com Ana. Antes de prosseguir, é importante destacar um ponto relevante sobre a apresentação da nova proposta de solução ao setor de negócios feita por Ana. Ela desenvolveu essa proposta em conjunto com as áreas responsáveis pelo sistema, chegando a uma conclusão sobre o que seria o melhor. No entanto, Ana, que está começando agora a atuar como arquiteta de soluções, ainda sente muita insegurança. Será que essa é a melhor solução? Mesmo tendo trabalhado em conjunto, a pessoa que atua como arquiteta de soluções deve assumir a responsabilidade. Não é possível responsabilizar outras pessoas caso a arquitetura não gere o resultado esperado ou cause outros problemas. Quem está à frente da arquitetura deve se responsabilizar, mesmo que tenha sido construída em conjunto com outras pessoas.

Utilizando inteligência artificial para verificar a solução

Para lidar com essa insegurança sobre a proposta, Ana utiliza inteligência artificial (IA) para verificar a solução. Hoje em dia, é algo muito comum usar IA para apresentar o panorama do problema mapeado e a solução proposta. A IA é solicitada a agir de forma crítica, com perguntas, questionamentos e apontamentos de eventuais problemas. Com esse suporte, vamos refinando a solução, usando a IA como copiloto, como assistente para a pessoa arquiteta de soluções. Isso é muito comum e acelera bastante o processo, ajudando a lidar com a insegurança em relação à solução proposta.

Na fase inicial, quando começamos a atuar como arquiteta de soluções, essa situação é bastante frequente. No entanto, mesmo após oito ou nove anos de atuação, a insegurança ainda pode surgir. Será que esse é o melhor caminho? A IA não substitui as interações necessárias para a pessoa arquiteta, mas ajuda a refinar vários pontos de forma muito eficaz.

Comunicando a proposta de arquitetura para as áreas de negócio

O que Ana fez a seguir? Após entender o problema de negócio e uma nova proposta de arquitetura, conhecendo melhor o problema atual e a arquitetura vigente, ela aprimorou ao máximo possível, interagindo com alguma solução de inteligência artificial. Inicialmente, Ana percebeu que não conseguiu se comunicar de forma clara com as áreas de negócio. Ela buscou uma forma de apresentar suas ideias sem utilizar um diagrama de arquitetura de software, então desenhou um fluxo de processo para mostrar como o novo processo se comportaria uma vez que essa arquitetura fosse aprovada por todas as áreas envolvidas.

Ana desenhou um fluxo, mostrando as pessoas envolvidas no processo: o cliente, o e-commerce e a plataforma de pagamento, para dar uma visão clara às áreas de negócio. Tudo começa com o cliente escolhendo o produto e enviando essa compra para pagamento. O e-commerce processa uma série de regras, abstraindo a questão de quantos sistemas existem e a mensageria. Para ela, não fazia sentido entrar nesses detalhes técnicos com a área de negócio, e concordamos que isso seria uma sobrecarga desnecessária.

Apresentando a visão clara do processo de pagamento

O e-commerce processa as regras e integra o pagamento com a plataforma de pagamento, que processará esse pagamento e, finalmente, notificará o cliente quando o pagamento for concluído. Essa é uma visão clara e sucinta, mostrando como a comunicação com o cliente seria estabelecida, sem entrar em pormenores técnicos. Se algum usuário mais avançado desejar, ele poderá consultar a documentação mais técnica. No geral, a visão da proposta e do resultado, e como pretendemos alcançar esse resultado, é suficiente para tranquilizar a área de negócio.

Na nova reunião com as áreas de negócio e os times envolvidos, Ana conseguiu transmitir uma visão clara para todos sobre os problemas mapeados através das entrevistas. Além disso, ela sugeriu focar inicialmente nos problemas relacionados ao pagamento, para, em seguida, quando isso estiver resolvido, todos abordarem o problema relacionado à clareza dos dados. Além disso, ela trabalhará com uma solução orientada à conversa com documentos, mas isso será assunto para outros capítulos deste projeto.

Focando na resolução dos problemas críticos

O ponto principal aqui é que Ana definiu o seguinte: vamos nos concentrar na cobrança e, com esse novo processo e proposta de solução, resolveremos os problemas mais críticos que foram mapeados até então.

No próximo vídeo, faremos uma recapitulação desse percurso de Ana e de alguns aprendizados que ela teve, e que as pessoas que estão começando a atuar como arquitetas de soluções provavelmente também terão. Obrigado!

Sobre o curso Arquitetura de Soluções: papel do arquiteto e pensamento sistêmico

O curso Arquitetura de Soluções: papel do arquiteto e pensamento sistêmico possui 166 minutos de vídeos, em um total de 46 atividades. Gostou? Conheça nossos outros cursos de Arquitetura de Software em Back-end, ou leia nossos artigos de Back-end.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Aula 1
• Aula 2
• Aula 3
• Aula 4
• Aula 5