Existe uma pergunta que acompanha praticamente todo profissional que trabalha com arquitetura:

“Mas, afinal, o que faz um Arquiteto de Soluções?”

A resposta parece simples.

Alguns dizem que é quem desenha arquiteturas.

Outros afirmam que é quem define tecnologias.

Há quem diga que é o profissional mais experiente da equipe.

Nenhuma dessas definições está completamente errada.

Mas todas são incompletas.

O problema é que a profissão evoluiu muito mais rápido do que as descrições existentes no mercado.

Hoje encontramos arquitetos escrevendo código.

Arquitetos fazendo pré-venda.

Arquitetos liderando times.

Arquitetos participando de reuniões executivas.

Arquitetos desenhando integrações.

Arquitetos definindo estratégia de cloud.

Arquitetos trabalhando com IA.

Então, afinal…

Existe uma definição única?

Neste capítulo construiremos essa definição.

Não baseada em cargos.

Não baseada em tecnologias.

Mas baseada no propósito da profissão.

Por que existe um Arquiteto de Soluções?

Antes de responder o que um arquiteto faz, precisamos responder outra pergunta.

Por que essa profissão surgiu?

Durante muito tempo o desenvolvimento de software era relativamente simples.

Poucos sistemas.

Poucas integrações.

Poucos usuários.

Pouca infraestrutura.

Com a evolução da tecnologia surgiram novos desafios.

• Sistemas distribuídos
• Cloud Computing
• Microsserviços
• APIs
• Eventos
• IA
• Segurança
• Escalabilidade
• Governança
• Compliance
• Custos de infraestrutura

Cada decisão técnica começou a impactar diretamente o negócio.

Uma escolha errada deixou de significar apenas código ruim.

Ela passou a representar milhões de reais desperdiçados, perda de clientes e projetos fracassados.

Foi nesse momento que surgiu a necessidade de alguém capaz de conectar dois mundos.

O mundo do negócio.

E o mundo da tecnologia.

A definição mais simples possível

Se eu tivesse apenas uma frase para definir um Arquiteto de Soluções, seria esta:

Um Arquiteto de Soluções é o profissional responsável por transformar objetivos de negócio em soluções tecnicamente viáveis, sustentáveis e capazes de gerar valor.

Perceba o que essa definição não fala.

Ela não cita AWS.

Não cita Azure.

Não cita Kubernetes.

Não cita Java.

Não cita microsserviços.

Porque essas coisas mudam.

O propósito permanece.

O erro mais comum

Existe um equívoco extremamente comum.

Acreditar que arquitetura é sobre tecnologia.

Não é.

Tecnologia é apenas uma ferramenta.

Arquitetura é tomada de decisão.

Toda decisão arquitetural responde perguntas como:

• Vale a pena construir isso?
• Vale a pena comprar?
• Quanto custa manter?
• Quanto custa evoluir?
• Qual risco estamos assumindo?
• Qual impacto para o negócio?
• Como isso escala?
• Como isso será operado?
• Como isso será monitorado?
• Quem dará suporte daqui a cinco anos?

Essas perguntas raramente aparecem em um curso de programação.

Mas aparecem diariamente na rotina de um arquiteto.

O arquiteto não resolve problemas técnicos

Essa frase costuma causar estranheza.

Mas vale repetir.

O arquiteto não resolve problemas técnicos.

Ele resolve problemas de negócio utilizando tecnologia.

Existe uma enorme diferença.

Imagine que uma empresa precisa reduzir em 40% o tempo de aprovação de crédito.

A solução pode envolver:

• IA
• Automação
• BPM
• Integrações
• APIs
• Machine Learning
• Ou apenas uma mudança simples no processo.

O objetivo nunca foi implementar IA.

O objetivo era reduzir o tempo.

A tecnologia é consequência.

O verdadeiro produto de um arquiteto

Desenvolvedores entregam software.

Designers entregam experiências.

Analistas entregam requisitos.

Qual é o produto entregue pelo arquiteto?

Decisões.

Todos os documentos produzidos por um arquiteto existem para registrar decisões.

Diagramas.

ADRs.

Documentos.

Apresentações.

Roadmaps.

Arquiteturas.

Todos são apenas representações de decisões.

Os cinco pilares da profissão

Introduzo aqui os pilares que serão aprofundados ao longo dos artigos.

Entender o negócio

Antes de qualquer tecnologia.

Projetar soluções

Traduzir necessidades em arquitetura.

Reduzir riscos

Segurança, disponibilidade, governança e continuidade.

Viabilizar a entrega

Garantir que aquilo possa realmente ser construído.

Gerar valor

Toda decisão precisa produzir algum benefício para a organização.

O arquiteto não trabalha sozinho

Existe outra visão equivocada.

A ideia de que o arquiteto fica isolado desenhando diagramas.

Na prática ele conversa o tempo inteiro.

Com clientes.

Com desenvolvedores.

Com infraestrutura.

Com segurança.

Com produto.

Com executivos.

Com fornecedores.

Com jurídico.

Com operações.

Quanto maior o projeto, menor o tempo dedicado à tecnologia e maior o tempo dedicado à comunicação.

Existe mais de um tipo de arquiteto?

Sim.

Arquiteto de Software.

Arquiteto de Soluções.

Arquiteto Corporativo.

Arquiteto de Infraestrutura.

Arquiteto Cloud.

Arquiteto de Dados.

Arquiteto de Segurança.

Embora possuam focos diferentes, todos compartilham um mesmo objetivo:

Tomar decisões que aumentem as chances de sucesso da organização.

(Este tema será aprofundado no próximo artigo.)

Conclusão

Ao longo da carreira conheci profissionais brilhantes tecnicamente que nunca conseguiram atuar como arquitetos.

Também conheci arquitetos que não eram os melhores programadores da equipe, mas eram capazes de enxergar problemas que ninguém mais via.

Isso acontece porque arquitetura não é um cargo.

Também não é um conjunto de tecnologias.

Arquitetura é uma forma de pensar.

É a capacidade de compreender um problema sob diferentes perspectivas, equilibrar interesses muitas vezes conflitantes e tomar decisões conscientes que aproximem tecnologia e estratégia de negócio.

No fim das contas, o trabalho do Arquiteto de Soluções não é construir sistemas.

É construir caminhos para que a tecnologia gere resultados reais.