Papel do Arquiteto de Soluções e Pensamento Arquitetural

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

Introduzindo os desafios de Ana na Amaral Seguros

Olá a todos, continuando nossa jornada de transição de desenvolvedores para arquitetos de soluções. Vamos conhecer os desafios que a liderança da Amaral Seguros apresentou a Ana para avaliar sua capacidade de atuar como arquiteta de soluções.

Ana recebeu algumas missões, e a primeira está relacionada à plataforma de e-commerce da Amaral Seguros. Parece que haverá desafios importantes. Essa plataforma cresceu de forma orgânica. Embora o time de engenharia seja muito talentoso, ainda enfrenta dificuldades na publicação de novas funcionalidades, que demoram cada vez mais para serem implementadas em produção. Além disso, o custo de manutenção da plataforma tem aumentado. Ana foi encarregada de conversar com as áreas de negócio para entender os problemas e elaborar uma proposta de solução.

Identificando os problemas na plataforma de e-commerce

Vamos entender o que a área explicou a Ana? Foram identificados três problemas principais: as vendas estão sendo afetadas, a imagem da empresa está prejudicada e os clientes estão insatisfeitos. Ana tomou nota desses problemas e seu primeiro instinto foi entender do que se tratava. Ela sabe que há oportunidades de refatoração e melhoria na base de código legado. Códigos ruins geram lentidão e erros que podem afetar a experiência dos clientes no e-commerce da Amaral Seguros. Isso foi o que lhe veio à mente inicialmente.

Ana elaborou uma estratégia e desenhou uma proposta de solução baseada no que conhecia, em sua zona de conforto, no que era especialista: o desenvolvimento de software. Após isso, convocou uma reunião com as áreas de negócio. No entanto, ao apresentar sua proposta, que estava muito focada em refatoração e mudança de frameworks (estruturas), as pessoas das áreas de negócio não entenderam. O gerente da área comercial até pediu que alguém tentasse traduzir o que Ana estava dizendo, pois ele não conseguia compreender. Quando Ana começou a falar de frameworks, refatoração de código e boas práticas de SOLID, isso não fazia sentido para as áreas de negócio.

Enfrentando desafios de comunicação e entendimento

Além disso, houve outro ponto agravante. O fornecedor da plataforma de e-commerce questionou a visão de Ana sobre as integrações e o funcionamento da solução, e como ela chegou à conclusão de que a refatoração do código era o caminho para resolver o problema. Essa é uma realidade que ocorre quando passamos do desenvolvimento de software para a arquitetura de soluções, tentando fundamentar as propostas totalmente no aspecto técnico, no código. O técnico será importante, mas não necessariamente o código. Usar termos técnicos diante das áreas de negócio gera ruído, algo que não costuma funcionar bem.

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

Refletindo sobre as falhas e buscando clareza

O pessoal explicou quais eram os problemas e nós supusemos que os havíamos entendido com base nesse relato inicial. Baseados nessa suposição, propusemos uma solução que, em nossa visão, era o melhor caminho a seguir. Assumimos algumas conjeturas, considerando certas coisas como certas, baseando-nos nos problemas que nos foram relatados inicialmente. Por último, não conseguimos nos comunicar com as áreas de negócio de forma eficiente. As pessoas não entenderam o que estávamos propondo. Talvez solucionasse, muito provavelmente não, mas o fato é que a mensagem não ficou clara. As pessoas não conseguiram entender o que estávamos transmitindo.

O grande ponto aqui é que, sempre que mapeamos um problema de negócio, devemos indagar e aprofundar quais são os pontos, quais são as consequências desse problema e como isso impacta realmente o negócio. Neste caso, o negócio da Amaral Seguros, uma empresa do setor de seguros. Por que as vendas estão sendo afetadas? A imagem da empresa está sendo prejudicada, por quê? Os clientes estão insatisfeitos, por quê? Porque a pergunta "por quê" é uma palavra mágica que pode abrir muitas portas relacionadas com a clareza de entendimento e ajudar na proposição de soluções.

Reavaliando a abordagem e buscando soluções

Ana entendeu que havia cometido um erro no enfoque inicial, mas, como brasileira, não se rendeu. Ela começou a analisar o problema a partir de uma nova ótica. A primeira estratégia que adotou 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, quais eram os detalhes desses problemas identificados inicialmente. Essa foi uma atitude muito inteligente.

Após essa conversa, a visão estava muito mais clara. Revisando o que ela mapeou, as vendas estão sendo afetadas porque o tempo de resposta da tela de cobrança é muito longo e com falhas, o que faz com que os clientes desistam. Problema 2: a imagem da empresa está sendo prejudicada, por quê? Quando conseguem contratar, o sistema fica bloqueado por bastante tempo. Então, o cliente contrata, o sistema fica bloqueado em uma tela da loja e não dá visibilidade sobre se o pagamento foi aceito ou não, e os clientes estão ficando bastante irritados com esse comportamento. O terceiro ponto é que os clientes estão insatisfeitos por tudo o que já ocorreu nos problemas 1 e 2, mas há um extra. Quem consegue contratar não tem uma forma fácil de acessar a informação do produto contratado. Então, no momento em que precisam acionar o seguro, não têm visibilidade das coberturas, das assistências, entre outros detalhes. Assim, a pessoa fica bastante insatisfeita. A experiência pós-venda também é bastante ruim, embora a experiência de pré-venda seja algo mais crítica.

Concluindo com lições aprendidas

No próximo vídeo, vamos desmembrar o que Ana fez, uma vez que passou a ter uma visão clara de qual era o problema e um recado importante. Sempre podemos ter dúvidas em relação à solução que vamos adotar, mas como pessoas que desenham soluções, nunca podemos duvidar sobre qual é o problema. Enquanto tivermos dúvidas, precisamos conversar com as pessoas, entender até ter uma clareza absoluta sobre qual problema deve ser resolvido, para depois ponderar as possíveis alternativas de solução.

Isso é tudo, até o próximo vídeo!

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 Papel do Arquiteto de Soluções e Pensamento Arquitetural

O curso Papel do Arquiteto de Soluções e Pensamento Arquitetural possui 166 minutos de vídeos, em um total de 45 atividades. Gostou? Conheça nossos outros cursos de Arquitetura em DevOps, ou leia nossos artigos de DevOps.

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