Revisitando o papel da pessoa arquiteta de software
Olá!
Hoje eu gostaria de comentar um pouco sobre o papel da pessoa arquiteta nas empresas e como essa dinâmica mudou um pouco ao longo do tempo. Boa parte desse texto foi baseado nas ideias propostas pelo Gregor Hohpe.
Vamos começar analisando essa posição com um modelo de como as organizações enxergam arquitetura de sistemas, no qual eu gostaria de usar uma imagem desse artigo aqui do mesmo autor:
Vou comentar brevemente sobre cada uma delas:
Ditador benevolente: Nesse modelo, a pessoa arquiteta possui poderes divinos sobre o que é o certo e errado em termos de design de sistemas e suas interações, deixando as pessoas desenvolvedoras somente como executoras de seu desenho sagrado. No entanto, há um pouco de esperança nesse modelo caso a relação com o ditador seja bi-direcional, ou seja, ao menos a pessoa arquiteta ouve o que o time executor tem a dizer. Caso contrário, é um modelo bastante perigoso, dado que uma única pessoa não é capaz de enxergar todas as perspectivas ao mesmo tempo de um determinado problema, por mais experiente que seja. Além disso, sofre influência da Lei de Conway, podendo gerar Big Ball of Mud ou sistemas complexos demais, dependendo bastante das limitações do conhecimento do ditador.
O primeiro entre iguais: Nesse cenário, o responsável pela arquitetura é alocado em um time específico, no qual consegue ajudar nas decisões arquiteturais de forma mais aprofundada e direcionada. O grande porém é que ainda sim, é uma única pessoa responsável por uma decisão tão impactante para o negócio. Não é um modelo ruim, dado que geralmente a pessoa desenvolvedora mais sênior do time toma quase todas essas decisões de longo prazo em várias equipes por aí — e até que funciona em muitos casos — , o único detalhe é que nesse modelo a pessoa arquiteta não recebe o título. E tá tudo bem.
Arquitetura sem arquitetos: Esse é o modelo mais adequado para organizações que querem ser exponenciais e que operam em modelos descentralizados. Nesse caso, todos os membros de todos os times dividem a responsabilidade pela arquitetura. Geralmente, é um modelo bastante saudável, desde que existam diretivas de arquitetura para auxiliar os times, senão se torna mais próximo do modelo do próximo parágrafo.
Os internos gerenciam o asilo: Além de nome de livro e de fase do jogo do Batman, a primeira vista parece que nem o modelo anterior, porém, é um eterno "deixa que eu deixo" na gestão da arquitetura que só tem como resultado possível o caos completo, pois pela falta de um dono da arquitetura não há um esforço consciente em direção a melhora da mesma. E sempre existe aquela máxima: o nível de consciência que gerou o problema dificilmente é o mesmo que consegue resolvê-lo.
Em tempos de trabalho presencial, a pessoa arquiteta conseguia aprender por osmose boa parte dos detalhes internos dos sistemas simplesmente porque era possível estar fisicamente no mesmo local que as pessoas desenvolvedoras. Porém, com a chegada da pandemia, as formas de comunicação entre as pessoas nas empresas mudaram consideravelmente, o que impactou significativamente essa capacidade de aprendizado. Afinal, hoje em dia você tem que marcar uma conversa se quiser falar com alguém sobre algo, obrigatoriamente. Portanto, para entendermos o novo papel da pessoa arquiteta, se faz necessário revisar as diversas dinâmicas de como a tecnologia como um todo é vista pelas empresas.
Os tipos possíveis propostos no modelo do Gregor estão resumidos na imagem abaixo:
Dito isso, temos:
Centro de custo: aqui temos as empresas tradicionais que enxergam a tecnologia como um problema. O foco está em cortar a maior quantidade de custos com infraestrutura e demais ferramentas relacionadas tanto quanto possível. Em outros termos, é um lugar horrível para se trabalhar se você é um profissional de tecnologia, pois nunca você verá que seu trabalho está contribuindo para a organização e você será invalidado o tempo todo. Ou pode até acontecer de todo o serviço de tecnologia ser terceirizado. Aqui reside um problema: tecnologia é core e core não se terceiriza, pois a falta de ownership de algo tão crítico gera resultados… peculiares.
Ativo: Nesse caso, o que importa é se a tecnologia é uma área geradora de resultado financeiro. O foco acaba em ser uma área de projetos, no qual o papel da tecnologia será não atrapalhar a operação de maneira alguma. É até aceitável alguns investimentos maiores, desde que tenham um ROI aderente ao investimento. Prepara-se para ver grandes projetos sendo aprovados para entregar um retorno vários meses depois. Acaba sendo até meio óbvio assumir que a tecnologia nesse tipo é vista como uma grande área executora de projetos e nem de longe a agilidade é aplicada como deveria. Aqui cabe mencionar um detalhe: a economia de escala é considerada (ou seja, quanto maior, melhor), o que não é necessariamente é a melhor abordagem em se tratando de tecnologia — mais detalhes adiante.
Parceira: Nesse caso, o foco é aumentar a agilidade na empresa inteira. Nesse tipo, existe a figura do Chief Digital Officer, que é uma pessoa executiva responsável por digitalizar tudo e puxar a "inovação". Ao meu ver, o que empresas tradicionais enxergam como inovação na tecnologia é simplesmente aplicar agilidade em tudo e não pensar muito sobre o resto (além de fazer um app só porque todo mundo tá fazendo). Porém, o que importa é a mentalidade digital e não somente métricas de vaidade que indicam o de uso de uma metodologia específica como Scrum, Kanban ou SAFe.
Enabler: Nesse cenário, o intuito da tecnologia e fornecer rapidez e inovação ao negócio. Aqui, a linguagem é a economia da velocidade (ou seja, quanto mais rápido e fácil, melhor). É nesse tipo de empresa que ocorrem os maiores investimentos em tecnologia e acaba sendo um lugar que está na vanguarda de inovações na percepção das pessoas desenvolvedoras no mercado de trabalho. Como o CTO responde direto para o CEO da empresa, a tecnologia acaba por ter um lugar a mesa e é vista como uma cidadã de primeira classe na comédia corporativa. Recomendo fortemente se você é uma pessoa desenvolvedora buscar esse tipo de ambiente para trabalhar, pois é onde você irá se desenvolver mais como profissional no longo prazo.
Agora vamos nos aprofundar no conceito do Architect Elevator, que é a proposta do Gregor para ajudar as pessoas arquitetas a encontrarem seu lugar a mesa nas dinâmicas das empresas, pelas palavras do mesmo:
Many large organizations see their IT engine separated by many floors from the executive penthouse, which also separates business and digital strategy from the vital work of carrying it out. The primary role of an architect is to ride the elevators between the penthouse and engine room, stopping wherever is needed to support these digital efforts: automating software manufacturing, minimizing up-front decision making, and influencing the organization alongside technology evolution.
Ou seja, a pessoa arquiteta precisa ter um certo jogo de cintura para ir tanto no low-level, codar e entender o custo e impacto de suas decisões nos times, quanto falar com os executivos e explicar o porquê de algumas decisões técnicas precisarem ser feitas, com a linguagem adequada a esse público. Como o arquiteto "sobe e desce" nas camadas da hierarquia, é daí que vem a expressão o elevador da pessoa arquiteta.
Para tal situação ocorrer, é fornecido algumas dicas (a maioria delas tem bastante relação com as idéias de Devops e Agilidade):
Arquitetura de Runtime: Não existe sucesso de aplicações cloud-native sem o runtime adequado. Portanto, a pessoa arquiteta precisa pensar em sidecars, observability, docker, kubernetes e demais conceitos relacionados, não somente em arquitetura de sistemas. Para tal, o uso de modelos como OAM ou o DAPR podem ajudar. Acredito que esse tipo de modelo irá se tornar mais popular ao longo do tempo. Se você ficou curioso, em uma análise de mercado da InfoQ, essas ideias estão bem na vanguarda:
Automação da Manufatura de Software: Como automatizar a escrita de código não é possível (dado a natureza única de cada sistema), tente automatizar o máximo possível do pipeline de deploy para reduzir tempo gasto com trabalho repetitivo e não agregador de valor. Com isso, há uma redução no tempo de entrega de forma considerável. Em última instância, automatizar é eliminar desperdício (Lean ❤).
Valide decisões em cima de loops de feedback: Ou seja, fique próximo do time o suficiente para colher feedbacks e iterar em cima dos resultados obtidos.
Minimize a quantidade de decisões logo de cara: Se os momentos iniciais de um software é onde menos se sabe sobre ele, porque tomamos decisões arquiteturais (ou seja, difíceis de mudar) neste momento? Vale muito mais a pena deixar para tomar a decisão no momento oportuno ou não tomar a decisão em absoluto. Em arquitetura, geralmente aquele que é mais cauteloso é o que ganha no longo prazo.
Faça a arquitetura aderente a um propósito: A recomendação é pensar arquitetura de uma forma adequada a um problema específico e não tentar fazer algo de uso geral. Portanto o uso de técnicas que permitem flexibilidade nas integrações (como usar REST, Async, Message Queues e afins), é bastante recomendado. Portanto, pense em uma arquitetura "adequada para um fim específico" ao invés de uma arquitetura "boa", pois não existe tal coisa.
Arquitete de forma adequada a evolução da empresa: Essa recomendação eu gostaria de ter conhecido faz mais tempo, teria me poupado grandes dores. Não adianta pensar em um pipeline hiper-automatizado se a cabeça das pessoas ainda pensam em GMUD, aprovações do gerente e comitês de aprovação. Portanto, faça as mudanças arquiteturais adequadas ao "estado de consciência" da empresa naquele momento.
Crie uma vertical de arquitetura: Apesar de parecer bastante com o modelo do benevolent dictator (nesse caso, troque uma pessoa por um time de ditadores que ditam as regras) mencionado anteriormente, o intuito é um pouco diferente. Esse time seria uma espécie de enabling team do team topologies, tendo poderes para trafegar entre todos os níveis da empresa, seja ouvindo os executivos e descendo a estratégia para os demais times, quanto ouvindo as pessoas desenvolvedoras e subindo as dores para os gestores. A idéia é reduzir o efeito telefone sem-fio entre a estratégia e execução.
Remova impedimentos no "andar" adequado: Sem mudar a mentalidade dos executivos, é impossível fazer mudanças, portanto, ao invés de lutar com barreiras culturais, convença os executivos primeiro. Sem isso, qualquer mudança está fadada ao fracasso, não importa o quanto bem intencionado ou certo você esteja.
E você, o que achou das ideias discutidas no texto?
Até!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
