A profissão que quase todo mundo conhece… mas poucos conseguem definir
Se eu perguntasse para dez profissionais de tecnologia o que faz um Arquiteto de Soluções, provavelmente ouviria dez respostas diferentes.
Alguns diriam que é quem desenha diagramas.
Outros afirmariam que é o profissional que escolhe tecnologias.
Haveria quem respondesse que é o desenvolvedor mais experiente da equipe.
Talvez alguém resumisse dizendo que é “quem toma as decisões”.
Curiosamente, todas essas respostas têm um pouco de verdade.
E, ao mesmo tempo, nenhuma delas consegue explicar completamente a profissão.
Esse é um dos poucos cargos da tecnologia cuja responsabilidade cresce muito mais rápido do que sua definição.
Hoje encontramos arquitetos participando de reuniões estratégicas com diretores, liderando iniciativas de transformação digital, apoiando equipes de desenvolvimento, desenhando integrações, conduzindo pré-vendas, avaliando fornecedores, projetando soluções em nuvem e, em muitos casos, ainda escrevendo código.
Diante de tudo isso, uma pergunta inevitavelmente surge:
“Mas, afinal, o que faz um Arquiteto de Soluções?”
Antes de responder, precisamos entender por que essa profissão passou a existir.
Por que existe um Arquiteto de Soluções?
Durante muitos anos, desenvolver software era uma atividade relativamente previsível.
As aplicações eram menores.
As equipes eram reduzidas.
Poucos sistemas precisavam conversar entre si.
Infraestrutura era um assunto restrito ao datacenter da empresa.
Com o tempo, esse cenário mudou completamente.
Cloud Computing, APIs, microsserviços, inteligência artificial, computação distribuída, requisitos de segurança, regulamentações, integrações e escalabilidade transformaram o desenvolvimento de software em um ambiente muito mais complexo.
Nesse novo contexto, uma decisão técnica deixou de afetar apenas o código.
Ela passou a impactar diretamente custos, prazos, riscos, experiência do cliente e até mesmo a estratégia da organização.
Alguém precisava ser capaz de enxergar esse cenário como um todo.
Alguém que entendesse o negócio, compreendesse as limitações técnicas e fosse capaz de transformar objetivos estratégicos em soluções viáveis.
Foi exatamente dessa necessidade que nasceu o Arquiteto de Soluções.
E isso nos leva à pergunta que realmente importa.
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.
Mas existe um erro que impede muitas pessoas de compreenderem essa definição.
O erro mais comum
O maior equívoco sobre arquitetura é acreditar que ela existe para resolver problemas técnicos.
Não existe.
Tecnologia é apenas o meio.
Arquitetura é tomada de decisão.
Sempre que um arquiteto participa de uma discussão, normalmente perguntas como estas estão presentes:
- Vale a pena construir ou comprar?
- Essa solução continuará fazendo sentido daqui a cinco anos?
- Quanto custará operar essa arquitetura?
- Quais riscos estamos assumindo?
- Como ela poderá evoluir?
- O que acontece se o volume de usuários dobrar?
- Como garantiremos segurança e disponibilidade?
Essas perguntas raramente aparecem quando estamos aprendendo a programar.
No entanto, elas fazem parte da rotina diária de qualquer arquiteto.
Mas ainda existe um detalhe importante.
Nem toda decisão arquitetural é, de fato, uma decisão técnica.
Antes disso, existe uma pergunta ainda mais relevante.
O arquiteto não resolve problemas técnicos
O arquiteto resolve problemas de negócio utilizando tecnologia.
Essa diferença parece pequena.
Na prática, ela muda completamente a forma de pensar.
Imagine que uma empresa tenha como objetivo reduzir em 40% o tempo de aprovação de crédito.
Alguém pode imediatamente sugerir Inteligência Artificial.
Outro pode propor automação.
Um terceiro defender microsserviços.
Talvez todas essas soluções sejam boas.
Talvez nenhuma delas seja necessária.
O verdadeiro objetivo nunca foi implementar IA.
Nem criar APIs.
Nem modernizar a arquitetura.
O objetivo era reduzir o tempo de aprovação.
A tecnologia só faz sentido quando aproxima a empresa desse resultado.
Quando entendemos isso, percebemos que o principal trabalho do arquiteto não é construir sistemas.
É tomar boas decisões.
O verdadeiro produto de um arquiteto
Desenvolvedores entregam software. Designers entregam experiências. Analistas entregam requisitos.
Mas qual é o produto entregue por um arquiteto?
A resposta pode surpreender: Decisões.
Diagramas são registros de decisões. ADRs registram decisões. Documentações registram decisões. Roadmaps registram decisões.
Até mesmo uma apresentação para um cliente existe para explicar e justificar decisões.
Tudo o que um arquiteto produz serve para tornar uma decisão compreensível, comunicável e sustentável ao longo do tempo.
Se o produto do arquiteto são decisões, surge uma nova pergunta.
O que diferencia uma boa decisão de uma decisão comum?
A resposta está nos pilares da profissão.
Os cinco pilares da Arquitetura de Soluções
Embora cada empresa tenha uma realidade diferente, existem cinco competências presentes em praticamente todo bom arquiteto.
Entender o negócio
Toda decisão técnica deve começar pelo problema de negócio.
Projetar soluções
Transformar necessidades em uma arquitetura coerente.
Reduzir riscos
Segurança, disponibilidade, custos, conformidade e continuidade operacional fazem parte da arquitetura.
Viabilizar a entrega
Uma boa arquitetura não é apenas elegante.
Ela precisa ser possível de construir com as pessoas, o orçamento e o prazo disponíveis.
Gerar valor
Se uma decisão não produz valor para a organização, dificilmente ela pode ser considerada uma boa decisão arquitetural.
Até aqui pode parecer que todas essas competências pertencem exclusivamente ao arquiteto. Na prática, não é assim.
O Arquiteto não trabalha sozinho
Nenhuma arquitetura relevante nasce da cabeça de uma única pessoa.
Ela surge a partir de conversas, negociações, alinhamentos e, muitas vezes, de opiniões conflitantes.
O arquiteto conversa com desenvolvedores.
Conversa com especialistas em infraestrutura.
Conversa com segurança.
Com produto.
Com operações.
Com fornecedores.
Com clientes.
Com executivos.
Quanto maior a organização, menos tempo o arquiteto dedica às ferramentas e mais tempo dedica às pessoas.
Por isso, comunicação é uma das habilidades mais importantes da profissão.
E existe outro efeito interessante dessa colaboração.
Quanto maior a empresa, maior também a necessidade de especialização.
É justamente por isso que encontramos diferentes tipos de arquitetos.
Os Tipos de Arquitetos
Em empresas menores, muitas vezes uma única pessoa acumula todas as responsabilidades relacionadas à arquitetura. Já em organizações maiores, essas responsabilidades costumam ser divididas.
É daí que surgem papéis como:
- Arquiteto de Software;
- Arquiteto de Soluções;
- Arquiteto Corporativo;
- Arquiteto Cloud;
- Arquiteto de Infraestrutura;
- Arquiteto de Dados;
- Arquiteto de Segurança.
Embora atuem em camadas diferentes da organização, todos compartilham a mesma essência.
Transformar problemas complexos em decisões que aumentem as chances de sucesso do negócio.
Nos próximos artigos exploraremos essas diferenças em detalhes.
Mas, antes disso, vale reforçar a principal ideia deste artigo.
Conclusão
Ao longo da minha 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 possuíam uma habilidade extraordinária para conectar tecnologia, pessoas e estratégia.
Isso acontece porque arquitetura não é um cargo.
Também não é uma lista 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 dos objetivos do 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.
E é exatamente essa forma de pensar que desenvolveremos ao longo deste livro.
E você?
Se alguém lhe perguntasse hoje, em uma única frase:
“O que faz um Arquiteto de Soluções?”
Qual seria sua resposta?
Escreva nos comentários. Quero conhecer diferentes perspectivas e trazer algumas delas para discussões futuras.
Se este artigo fez sentido para você, compartilhe com outros profissionais de tecnologia. Quanto mais pessoas compreenderem o verdadeiro papel da arquitetura, melhores serão as soluções que construiremos juntos.
No próximo artigo
Agora que entendemos o propósito da profissão, surge uma dúvida inevitável.
Qual é, afinal, a diferença entre um Arquiteto de Software, um Arquiteto de Soluções e um Arquiteto Corporativo?
Embora esses cargos sejam frequentemente confundidos, cada um atua em uma camada diferente da organização e responde por decisões completamente distintas.
Falaremos sobre isso nos próximos artigos.
Deixe um comentário