Introdução

Nesse artigo apresento uma visão geral sobre Team Topologies
Exploro os principais motivadores e trago um panorama histórico sobre Team Topologies
No final apresento um Caso de Uso real que foi desenvolvimento para um motor de abastecimento de uma aplicação comercial Brasileira em IoT e App-First.

Descobrindo Team Topologies

O livro Team Topologies, escrito por Matthew Skelton e Manuel Pais, foi lançado em outubro de 2019. Entre 2019 e 2020, a área de Serviços de Tecnologia experimentou uma explosão de contratações em uma escala sem precedentes na história, impulsionada por três principais fatores:

Otimização da dinâmica organizacional para viabilizar a transformação digital;
O avanço do paradigma Cloud-Native, que, desde 2010, vinha sendo limitado por barreiras econômicas e tecnológicas, mas encontrou um momento propício para expansão com as plataformas da AWS, GCP e Azure (vide ZIRP);
A pandemia da COVID-19, que impôs desafios globais sem precedentes na saúde pública, impactando diretamente a economia e a sociedade.

Diante desse cenário, empresas e organizações precisaram revisitar, adaptar e redefinir suas dinâmicas organizacionais para alinhar de forma mais eficiente tecnologia, pessoas e negócios.

Foi nesse contexto que me apaixonei pelo tema de Team Topologies, pois ele abarcava conceitos que sempre me interessaram profundamente. Minha conexão com o assunto remonta e traz uma conexão também na época que cursei meu doutorado em Engenharia de Software, no qual estudei as dificuldades dos desenvolvedores na compreensão de código e modelos e como esses desafios estavam diretamente relacionados à carga cognitiva.

Visão Geral sobre Team Topologies

O que precisamos em uma organização é uma evolução contínua e gradual acionada tanto pelas equipes quanto pela gerencia, ao invés de grandes revoluções geradas com top-downsManuel Pais (Team Topologies Distilled)

Team Topologies expandiu meu olhar em uma direção mais profunda nos seguintes pilares de Engenharia de Software. Os termos traduzidos aqui foram extraídos do Github oficial do Team Topologies

Team First — refere-se a uma abordagem em que a equipe é tratada como a unidade central de valor dentro da organização, priorizando sua estabilidade, harmonia, autonomia e desempenho sustentável ao longo do tempo. Nesse contexto, Team Topologies promove a organização de equipes seguindo o princípio de Team First, visando estabelecer fluxos de valor alinhados ao negócio, com maior autonomia e menos bloqueios.
Organização e Re-Org de Equipes — Equipes são mais do que grupos de pessoas trabalhando juntas. Elas cooperam, interagem, confiam umas nas outras e realizam o trabalho em conjunto como uma unidade funcional, entregando valor de forma rápida e com alto desempenho. As equipes devem ser pequenas (cerca de 6 a 9 pessoas), coesas e de longo prazo, garantindo durabilidade e sustentabilidade. Uma equipe não é apenas um grupo de indivíduos, mas um sistema de dinâmicas e interações humanas. Por exemplo, não faz sentido que um indivíduo faça parte de duas ou mais equipes simultaneamente, pois isso o levaria a dividir suas responsabilidades, aumentando sua carga cognitiva e reduzindo tanto sua confiança quanto seu engajamento dentro da equipe. Além disso, especialistas devem atuar como mentores e influenciadores para fortalecer a confiança mútua e garantir a colaboração efetiva dentro da equipe.
Carga Cognitiva — refere-se à sobrecarga mental necessária para que um desenvolvedor processe uma atividade (task) e está diretamente relacionada ao fluxo rápido de entrega de valor. A Carga Cognitiva deve ser encarada como um bloqueio multidisciplinar, ou seja, vai além do uso de ferramentas e processos. Ela pode ser impactada por fatores como multitarefa, excesso de reuniões de alinhamento, revisões de código frequentes, retrabalho, dependência para tomada de decisão, microgerenciamento e falta de autonomia.
Arquitetura Sociotécnica — refere-se ao conjunto de relações entre Sistemas Sociais (pessoas e organização) e Sistemas Técnicos (estruturas e tarefas). A Arquitetura Sociotécnica envolve estratégias para o alinhamento da Arquitetura de Software, considerando que pessoas e equipes possuem a mesma importância que os aspectos técnicos, e vice-versa. Seu objetivo é viabilizar um fluxo rápido (fast-flow), fortemente apoiado em Domain-Driven Design (DDD) e na Manobra Reversa de Conway.
Arquitetura de Domínios com Domain-Driven Design — Domínios e Domain-Driven Design (DDD) são um dos pilares do Team Topologies, permitindo o alinhamento estratégico e tático das equipes em relação aos domínios. A decomposição de domínios possibilita o estabelecimento de Contextos Delimitados (Bounded Contexts), além da definição de modelos canônicos para a comunicação entre esses contextos. Com práticas como Event Storming e Context Mapping, é possível identificar e mapear fronteiras, além de definir e orientar os domínios dentro do espaço problema-solução.
Trust Boundaries — Contextos de Confiança é um conceito que vai além do Bounded Context, relacionando-se com a definição de fronteiras saudáveis e altamente confiáveis entre equipes e suas interações, tanto em relações internas (intra) quanto externas (inter). Estabelecer uma Fronteira de Confiança entre equipes promove maior agilidade na entrega, menor carga cognitiva, mais autonomia e interações claras e bem definidas.
Lei de Conway — Em 1967, Melvin Conway formulou a ideia de que o software que produzimos reflete a estrutura de comunicação organizacional. A Lei de Conway atua como um espelho — imagine um barco em um rio e seu reflexo na água — onde a estrutura organizacional influencia diretamente a arquitetura dos sistemas, impactando a forma como desenhamos e desenvolvemos software. Conway trouxe à tona uma série de fatores que direcionam o design de soluções de software, evidenciando fenômenos de homomorfismo, ou seja, a preservação de forma e propriedades entre dois modelos: organização e arquitetura. Alguns exemplos de fenômenos homomorfos incluem: (a) Limites estruturais do design da solução baseados na organização; (b) Linhas de comunicação que seguem o modelo organizacional (organograma ou org chart); (c) Disfunções entre o modelo de comunicação organizacional e seu reflexo no código-fonte; (d) Pensamento monolítico versus a adoção de capacidades técnicas compartilhadas.
Manobra Reversa de Conway — A Manobra Reversa de Conway é uma abordagem que propõe modificar a estrutura organizacional para que ela reflita a arquitetura de software desejada, promovendo um fluxo de valor mais eficiente. Em um excelente artigo, Ruth Malan reformula a Lei de Conway, afirmando que:

“Se a arquitetura de software e a arquitetura organizacional estiverem em conflito, a arquitetura organizacional vencerá.”

Stream-alined Team — Equipe Alinhada ao Fluxo é um tipo de equipe que entrega um fluxo rápido de valor independentemente com um senso de propósito e autonomia. Ele é responsável por um fluxo end-to-end de entrega contemplando produtos e serviços. Equipes alinhadas ao fluxo devem ser pequenas e coesas (seguindo o número de Dumber entre 5 e 9 pessoas), devem ser multidisciplinares, independentes, coesas e com senso de propósito. O conceito independentemente é definido como sendo a delimitação funcional e ausência de qualquer conhecimento sobre detalhes de outros fluxos de valor (ou contextos), um exemplo disso é o memo de Jeff Bezos sobre APIs na Amazon. Além disso, a carga cognitiva de uma equipe alinhada ao fluxo deve ser baixo. Em geral, as principais capacidades envolvidas em uma equipe alinhada ao fluxo são: User Experience (UX), experimentação, customer-centric, métricas e feedback-loops.
Platform Teams— Equipe de Plataforma é um tipo de equipe que é responsável por construir uma fundação de APIs self-services, ferramentas e serviços, suportar e facilitar o conhecimento, arranjado como um pacote de produto interno. Uma equipe de plataforma remove impedimentos, apoia na redução da carga cognitiva de equipes alinhadas ao fluxo de valor. Criam meios para um caminho com menor resistência para fazer a coisa certa da maneira mais simples possível. Uma equipe de plataforma deve ser pensada como um Thinnest Viable Platform (TVP) que é o menor conjunto possível de APIs, documentação, serviços e ferramentas necessário para acelerar equipes modernas de desenvolvimento de software.
Enabling Team — Equipe Facilitadora ou Habilitadora é um tipo de equipe com um propósito bem definido que é o de mentorar, treinar e capacitar outras equipes (especialmente Equipes Alinhadas ao Fluxo — Stream-Alined Team) e promovendo a redução de carga cognitiva intrinsica e extrinsica das equipes. Possui um conjunto de especialistas dedicados, e em geral, rodam por um período de tempo limitado.
Complicated-subsystem Team— Equipe de subsistema complicado é um tipo de equipe opcional, que deve ser adotado com cautela, pois, dependendo do contexto, pode se tornar um gargalo no atendimento às demandas. Esse tipo de equipe é composto por especialistas altamente qualificados, como PhDs ou profissionais com alto nível de especialização técnica em áreas específicas, como AWS. Deve ser entendido como uma mini equipe de plataforma (mini-platform), cuja função é absorver a complexidade subjacente e reduzir a carga cognitiva das equipes alinhadas ao fluxo de valor. Em muitos casos, essa equipe pode ser incorporada por uma equipe de plataforma no futuro. Exemplos de equipes de subsistema complicado incluem: Desenvolvimento de recursos nativos de autenticação biométrica facial. Em minha experiência como Arquiteto de Software, precisei lidar com um sistema de leitura transacional de abastecimento para pagamentos em postos de combustíveis via IoT. Nesse contexto, tínhamos um Time de Complicated-Subsystem chamado IoT Fuelling.
Modelos de Interação como Facilitação, X-as-a-service, e Colaboração são modelos de interação entre equipes, podendo ser de Colaboração onde dois ou mais times compartilham um objetivo e resultado comum e precisam colaborar por um período de tempo em um discovery; X-as-a-service é um modelo de interação entre dois ou mais times onde são estabelecidas as capacidades de dependências via APIs com expectativas clareas e bem definidas; e por último Facilitação é um caminho para habilitar a facilitação, mentoria e capacitar outros times em atividades durante um período de tempo. Em geral, a Facilitação é utilizada como uma ativdade hands-on, prática e que possa reduzir a carga cognitiva de outros times. De modo controverso, a Facilitação quando executada por Stream-Aligned Teams ou Platform Teams pode elevar a carga cognitiva desses times. Por isso, esse relacionamento deve ser na maioria das vezes, realizado por Enabling Teams. Ressalta-se que nem todo participante no processo de Facilitação tem capacidade de mentoria e educação o que pode ser um desafio especialmente para especialistas técnicos.

Caso de Uso: Como Team Topologies e DDD ajudou a modelar um Motor de Abastecimento via IoT e App-First

A uns anos atrás atuei na Raizen e Shell Box em um projeto App-First e Customer-Centric, focado em pagamentos e fidelização de consumidores em postos de combustíveis, operando em escala nacional e internacional. Atendendo e suportando mais de 20 milhões de clientes e mais de mil postos de abastecimento em todo o Brasil.

Em 2021/2022, a aplicação enfrentou desafios para escalar, incluindo falta de clareza nos objetivos, ausência de uma visão estratégica de futuro para a arquitetura e sobreposição de papéis e responsabilidades.

Diante dessas dificuldades, foi necessária uma redefinição estratégica, reposicionando pessoas com base em direcionamentos e objetivos intencionais. Para isso, as equipes foram remodeladas e reorganizadas, realocando profissionais em frentes de valor alinhadas a Domínios, além da criação de Equipes de Plataforma, Equipes Habilitadoras, Equipes de Subsistema Complicado e Equipes Alinhadas ao Fluxo.

Essa nova estrutura permitiu uma evolução gradual da organização, com foco na consolidação de Equipes de Plataforma. Um exemplo dessa remodelagem foi a redefinição do papel dos Arquitetos, que passaram a atuar como Enabling Teams, com foco na evolução da arquitetura no médio e longo prazo.

Mapeando Oportunidades

A Figura 1 a seguir ilustra um dos passos utilizados para a re-estruturar e identificar sinais estranhos e que foram utilizados para mapear e re-estruturar os Times e a Arquitetura com foco em Team First.

A Figura 2 ilustra as premissas para direcionar uma evolução com base em Team Topologies, DDD e principalmente EventStorming. Para maiores detalhes sobre todo o processo de evolução consulte a apresentação realizada no DevPira 2022 e disponínel no Github.

Team Topologies foi utilizado como inspiração para modeladem de Times, Domínios e Fluxos Independentes.

Modelando Domínios para Stream-Aligned Teams Independente

A Figura 3 ilustra um diagrama relacional de dependencia que foi utilizado para direcionar a dependência entre Domínios e Subdomínios com foco no contexto de Abastecimento (Fuelling).

Modelando Team Topologies com Domínios e Stream-Alined Teams Independentes

A Figura 4— Ilustra uma modeladem de Domínios (parcial) indicando um Time Fuelling IoT que reflete uma jornada especializada e complexida para a leitura da volumetria de abastecimentos em near-real time hospedada em um sistema embutido em um mini-pc e/ou Raspberry Pi. Esse Time foi organizado como Complicated Subsystem uma vez que exigia um alto grau de inovação e especialização de pessoas com conhecimento em AWS IoT Core, comunicação de near-real time, paralelismo, e de protocolos em Restfull API, MQTT, SNS/SQS e banco de dados não relacional.

Um destaque especial se dá para o modelo de interação entre o Time de Arquitetura e System Team, junto com os fluxos de valores e Times de Plataformas. Nesse caso, sendo um time Enxuto e com responsabilidades de médio e longo prazo sendo responsáveis por boas práticas de arquitetura, recomendações e governança arquitetural. Essa prática consolida a visão do Time de Arquitetura como um Enabling Team também proposto por Eduardo Silva

Lições Aprendidas

O modelo de visão organizacional de Team Topologies se estabelceu como um padrão aberto e bem consolidado de uso e aplicação, especialmente no contexto do exemplo apresentado para uma organização de grande porte
Usar Domínios — sobretudo DDD e EventStorming — combinado ao modelo de Team Topologies promove uma melhor estabilidade arquitetural uma vez que os 4-pilares de Arquitetura Sociotécnica são utilizados (Pessoas, Tarefas, Sistemas e Infraestrutura).
Team Topologies traz luz e clareza sobre gaps e oportunidades, sobretudo quando a modernização for guiada pela Manabora Reversa da Lei de Conway.
Os conceitos e mentalidade sobre o uso de Team Topologies, DDD e Arquitetura Sociotécnica podem provocar e sensibilizar mudancas importantes por isso, compreender a maturidade de Times, e principalmente da Liderança é essencial para introduzir esses conceitos
Como experiência prática, introduzir os conceitos de Team Topologies, DDD e Arquitetura Sociotécnica não é uma tarefa trivial. Exige reforço, cautela e gestão de riscos. Existe um aprendizado constante, e influência dentro das organizações.
Também é importante reforçar que todo movimento deve ser incremental, gradual e evolutivo. Movimentos grandes, de re-estruturação de toda a organização nunca geram resultados positivos uma vez que rupturas, e altas cargas cognitivas ligadas a mudança impactam a motivação de pessoas dentro das organizações e consequentemente o ROI dos projetos.

Conclusão

Team Topologies desde quando foi lançado teve um impacto direto em como pensamos e direcionamos a visão evolutiva de arquitetura e organização.

Em especial com um olhar que combina as dimensões — Pessoas, Tarefas, Sistemas e Infraestrutura— envolvendo habilidades sociotécnicas. Muitas vezes nos deparamos com dificuldades de modernização de arquiteturas e o foco, que um arquiteto tem que oferecer é sobre tread-offs e opções sistêmicas.

O papél do arquiteto é muito mais do que apenas escolher as opções de soluções — como em um menu de um restaurante e recomendar uma opção.O arquiteto moderno deve lidar com os desafios organizacionais e reconhecer que existe uma restrição humana além de sistêmica; e que essa restrição é como as pessoas conseguem lidar com suas atividades e as interações cogntivas inerentes do dia-a-dia, para então produzirem as melhores arquiteturas.

Team Topologies — Desafios, Oportunidades e Lições AprendidasCaso de Uso: Como Team Topologies e DDD ajudou a escalar um Motor de Abastecimento via IoT e App-First