Quando falamos de arquitetura de software falamos do “arquiteto”. Como já falamos neste blog várias vezes, a arquitetura é a disciplina de tomar decisões que são difíceis de reverter depois. O “arquiteto” é a pessoa responsável por essas decisões. Não apenas tomar as decisões, mas lidar com as consequências.
Enquanto todo o design é uma via de mão dupla em que você pode tomar uma decisão, fazer uma mudança, e se não gostar, tomar a decisão contrária e reverter tudo, a arquitetura é a parte do design sobre decisões sem volta. Uma vez tomada a decisão e implementada, revertê-la será muito caro ou demorado o que torna a reversão, na prática, impossível. Um exemplo deste tipo de decisão é a escolha da linguagem em que o software será construido. Uma vez construido será impossível – leia-se proibitivamente caro – reverter a decisão e escrever em outra linguagem. Nada nos impede de escrever em outra linguagem, mas terá que ser tudo reescrito do zero; o que, claramente, não é economicamente viável.
Quando falamos de arquitetura e do papel de arquiteto, pode passar a impressão que só há um tipo de arquiteto que decide sobre todos os tipos de assunto. Não. Existem vários tipos de arquitetos. Uma pessoa pode desempenhar o seu papel de arquiteto em um ou mais destes tipos e, como estão relacionados, cada pessoa no papel de arquiteto – mesmo que especializado em um tipo – precisa compreender os outros.
Em equipes maiores pode ser que cada tipo seja desempenhado por uma pessoa diferente, ou que alguns dos tipos não esteja representado. Isto é comum. É comum inclusive que ninguém exerça explicitamente o papel de arquiteto e cada membro da equipe tem que fazer o seu melhor. Este é o pior cenário, mas bem mais comum do que se pensa.
Dentro da arquitetura existem diferentes perspectivas que levam aos diferentes tipos de arquiteto. Estas perspectivas variam em escopo e nível de detalhe.
| Tipo de Arquiteto | Escopo e Detalhamento |
| Corporativo (Enterprise) | É o escopo mais alto e com menor nível de detalhamento. É longe de tecnologias e mais perto dos objetivos da empresa e dos negócios. O seu trabalho é sobre como conhecer, organizar e manter o parque tecnológico da empresa, tanto em hardware como em software. |
| de Soluções | Neste escopo a pessoa lida com o trabalho de passar as ideias para o software. É responsável por atividades de levantamento e análise de requisitos, qualidade e progresso do trabalho. O seu escopo de atuação pode abranger vários software ao mesmo tempo. |
| de Domínio | “Domínio” aqui não significa o mesmo que em DDD. Significa a especialidade do arquiteto; a área de atuação. Por exemplo, Arquiteto de Segurança, de Dados, de Infraestrutura, de nuvem, etc. Neste escopo também se inclui o Arquiteto de Software que se preocupa com o código, aplicação de regras e boas práticas de design, SOLID, etc. Este é o escopo mais baixo e com maior nível de detalhe. Arquitetos neste nível têm que saber usar as ferramentas da sua área e dominar os princípios que regem essa área para além das ferramentas. Normalmente este nível implica em alguma dose de programação. |
Este é o arquiteto que mais perto trabalha dos outros órgãos da corporação. Ele precisa alinhar as decisões com a visão de longo prazo da corporação. Como as decisões de arquitetura são de muito longo prazo – de 8 a 12 anos – as decisões do arquiteto neste papel têm que apoiar e estar alinhadas com a visão corporativa de longo prazo. Sem uma visão por parte da corporação, este papel não tem valor.
O arquiteto corporativo tomas as decisões de mais longo prazo e se preocupar com o “big picture”, mas não tanto com os detalhes da solução em si – ou seja, não importa muito o que aplicação faz, mas sim que tipo de recursos precisa. A sua preocupação é com custos, prazos e outros recursos. As escolhas são feitas com base na vida da empresa e não tanto da tecnologia, do produto ou do código.
Este é o tipo de arquiteto que cai muitas vezes no antipadrão da Torre de Marfim. Esta pessoa pode estar tão longe dos pormenores que toma decisões desastrosas. Este também é o tipo de arquiteto mais influenciável por pessoas externas à companhia, especialmente vendedores de tecnologia. Este é o arquiteto que é abordado quando uma empresa de Cloud quer convencer a empresa a migrar para a sua nuvem ou um provedor de dados quer que a empresa compre seu banco de dados.
É recomendado que a pessoa neste papel não esteja apenas neste papel e não seja a única neste papel. Isto pode causar problemas de direcionamento tecnológico errado, mudanças muito frequentes de direção – e portanto caras – ou inconsistências. Devido à influencia externa uma pessoa sozinha nesta posição pode convencer os outros departamentos sobre gastar uma verba adquirindo certa tecnologia, quando na realidade não será usada, não é eficiente, ou nenhum dos programadores a saber usar.
É comum este papel ser desempenhado por um conselho de arquitetos de outros tipos.
Este é o arquiteto mais preocupado com o dia a dia do software. Coletar requisitos, analisá-los e desenhar soluções que atendam esses requisitos. Os requisitos em si podem ser de vários tipos, desde performance a regras de negócio, passado por problemas de UI.
Este tipo de arquiteto tem a visão do todo de como a solução funciona e como cada software se encaixa nessa solução; o papel de cada peça do puzzle. Contudo, não vai muito fundo nos detalhes de como criar, ou organizar o código do software em si, a sua visão é mais conceitual.
Este é o tipo de Arquiteto que tem experiência com modelagem de negócios e possivelmente com Domain Driven Design. Os artefatos produzidos pelo Arquiteto são normalmente documentos escritos com diagramas UML – ou semelhante – no nível conceitual dos conceitos de negócio. Normalmente não é necessário saber programar, mas é necessário conhecer Modelagem Orientada a Objetos.
O arquiteto de solução é responsável pelo andamento do desenvolvimento, evolução e manutenção (muito parecido com o papel do PO) e por isso ele é responsável por decidir sobre débitos técnicos. Quando tomá-los e quando pagá-los. Por outro lado, o Arquiteto de Solução é responsável pela qualidade da solução. Testes que testam a aplicação – não o código – são usados por ele para verificar que os requisitos estão sendo cumpridos. Se existir um departamento de QA é o Arquiteto de Soluções que utiliza os serviços desse departamento para entender o quão aderente ao requisitos foi a implementação, de novo, de forma muito semelhante ao papel do PO em ágil.
O arquiteto de solução é responsável por seguir, e fazer seguir, as diretivas escolhidas pelo Arquiteto Corporativo.
Cada domínio tem as sua especificidades e hoje em dia é complicado uma só pessoas saber de todas. Por outro lado há interações entre os vários papeis de Arquiteto de Domínio que são comum. Por exemplo, um arquiteto de software tem que conhecer o mínimo de como interagir com dados ou com segurança e é frequente que um arquiteto tenha conhecimento de vários domínios em diferentes graus de profundidade.
Por outro lado os domínios podem ser tão específicos que as decisões nesse campo só precisam ser tomadas uma vez, ou tão esporadicamente que talvez não é necessária uma pessoa dedicada exclusivamente a esse papel. Neste caso a contratação de consultores externos é uma prática comum.
Existem mais Arquitetos de Domínio, do que aqueles referidos aqui, mas os referidos aqui são os mais frequentes em softwares corporativos.
O Arquiteto de Software é responsável pela organização do código, do estabelecimento de boas práticas e da vistoria do cumprimento destas regras.
O seu papel não é relacionado ao que o software faz, mas sim a como o código é organizado para garantir que o software continuará fazendo o seu papel por muito tempo. O objetivo é facilitar a implementação, manutenção e evolução dos modelos criados pelo Arquiteto de Solução.
O nome deste tipo de arquiteto causa um pouco de confusão, especialmente entre o departamento de Recursos Humanos. O nome parece ser genérico – afinal estamos falando de “tipos de arquitetos em software” e é fácil confundir o “em” com o “de”- mas é na realidade muito especifico. Na contração, as pessoas do RH podem estar procurando um qualquer dos tipos de arquitetos mencionando neste artigo, mas como não conhecem as especificidades de cada um criam vagas com o nome genérico “Arquiteto de Software” achando que estão sendo abrangentes, quando estão fazendo exatamente o contrário.
Contratar uma pessoa para este papel significa ter alguém para decidir e implementar a configuração de arquitetura. Falamos de camadas, design patterns, SOLID e outros princípios que permeiam a escrita do código.
O arquiteto de software tem que garantir que o design do arquiteto de solução é possível ser implementado em tempo hábil, mas também que poderá ser corrigido e evoluído em tempo hábil.
O arquiteto de dados é aquela pessoa que se preocupa com a informação do software. Como recolhê-la, como guardá-la, como consultá-la e como mantê-la. Análise de dados, Business Inteligence, produção de relatórios, cruzamento de dados e inteligência artificial aplicada aos dados, são exemplos das preocupações e skills da Arquitetura de Dados.
Não é normalmente relevante de onde ou como os dados são obtidos desde que eles sejam confiáveis, ou seja, que nenhum adversário tenha manipulados os dados antes deles serem coletados.
O arquiteto de infraestrutura se preocupa com a fronteira entre o software e o hardware que é necessário para produzir e manter o software. As ferramentas, a segurança, a disponibilidade, a rede, a nuvem, enfim o que normalmente chamamos de infraestrutura. Preocupações com velocidade do CPU, memória RAM, capacidade de disco, permissões de rede e configuração de portas são exemplos das decisões do Arquiteto de Infraestrutura.
Este é o arquiteto que procura que o software seja seguro. Existem muitas coisas que podem ser alvo de adversários mal intencionados. Toda a decisão de arquitetura pode ser um potencial furo na segurança. Isto implica interagir com os outros arquitetos para garantir que cada um toma as providencias necessárias no seu campo de atuação de forma que o software como um todo, e os seus dados, não sejam invadidos, raptados ou corrompidos.
Como disse, existem outros tipos de arquitetos, estes são exemplos para clarificar que existem muitas áreas que precisam ser abrangidas pelas decisões do arquiteto e muitas vezes em simultâneo.
O papel do arquiteto não nasce como uma evolução do papel de desenvolvedor. É necessária uma preocupação extra com a qualidade das decisões, o seu custo, e como elas afetam o futuro – sempre que possível tornar as decisões irreversíveis em decisões reversíveis.