Arquitetura com 800 amigos: a Evolução do Architecture Guild da Comcast

Introdução: Tomada de decisões descentralizada

Não faz tanto tempo que era comum encontrar equipes centralizadas de revisão de arquitetura em grandes empresas de tecnologia: uma equipe que revisava todos os projetos para garantir sua consistência de acordo com a visão global da empresa. Quando a TI era vista principalmente como centro de custos, isso fazia sentido, pois a padronização e a consistência são uma boa forma de controlar os custos de manutenção.

Mas hoje há uma explosão no número de tecnologias em uso nas nossas empresas. Para cada projeto popular de código aberto, é bem provável que algum grupo o esteja usando em produção. Ao mesmo tempo, a necessidade de consistência e os seus benefícios permanecem.

Como chegamos a esse ponto?

Nossa indústria avançou na direção de capacitar equipes ágeis a tomar suas próprias decisões técnicas. Daniel Pink, em seu livro "Drive", identifica a autonomia como um dos três principais impulsionadores do comprometimento dos funcionários. O Manifesto Ágil [6] recomenda:

Construa projetos em volta de pessoas motivadas. Forneça para eles o ambiente e o suporte de que precisam e tenha confiança que farão o trabalho necessário.

e

As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas.

Até mesmo publicações de negócios divulgam os benefícios desse empoderamento, com artigos como "Impulsionar a tomada de decisões no local de trabalho" (Wall Street Journal) [1], "Porque as equipes autogeridas são o futuro dos negócios" (Revista Inc.) [2], e "Empoderados: Liberte seus funcionários, energize seus clientes e transforme seus negócios" (Harvard Business Review Press) [3]. Mas por que isso acontece?

Um dos motivos é a demanda por maior agilidade organizacional. John Boyd, em seu estudo de pilotos de caça militares, identificou que os pilotos que passavam mais rapidamente pelos ciclos de uma estratégia de tomada de decisões, chamada de OODA (Observar-Orientar-Decidir-Agir), poderiam vencer um combate interrompendo os ataques de seus oponentes com essa estratégia. A ideia foi adotada, desde então, pela comunidade empresarial, uma vez que a necessidade de tomar decisões rápidas é necessária em áreas altamente competitivas.

Outro motivo é simplesmente uma questão de produção e de escala. A Lei de Escalabilidade Universal diz que é limitada a taxa de produção máxima de sistemas (incluindo sistemas organizacionais de pessoas cooperantes) pela quantidade de contenção por recursos compartilhados e pela coerência necessária para manter todos atualizados sobre o que está acontecendo.

Na medida em que as empresas técnicas e a demanda por seus serviços crescem com o uso extenso do software, é natural que equipes centralizadas de revisão de arquitetura sejam descartadas, por serem pontos de gargalo; ou por ter havido redução do tamanho das equipes visando ao trabalho independente de cada equipe.

Segundo a Lei de Conway, arquiteturas de sistemas espelham os padrões de comunicação das equipes que os construíram. Se passamos tanto tempo tentando capacitar as equipes para trabalhar e decidir sem coordenação, não é de surpreender termos chegado a uma situação com tanta heterogeneidade técnica.

A necessidade de estrutura

Há uma colônia de fungos no Oregon com cerca de 9 quilômetros quadrados e 2.400 anos de idade. É certamente um organismo que deu certo! Porém essa colônia tem escala mas não estrutura; é apenas um conjunto gigante de cogumelos. Na biologia, vemos que a evolução desenvolveu vários níveis de estrutura － sistemas musculares, esqueléticos ou nervosos, por exemplo － como maneira eficiente de viabilizar algumas capacidades. Vemos o mesmo em sistemas de grande escala criados por pessoas.

O sistema de estradas interestaduais, por exemplo, permite o transporte de longa distância com mais eficiência do que seria possível com rodovias locais. Até a arquitetura da ARPANet original tinha tráfego entre sites através de links compartilhados; uma malha totalmente conectada teria sido inviável.

As organizações técnicas também podem se beneficiar desse tipo de estrutura e padronização. Em vez de usar vários produtos comerciais de fornecedores concorrentes, uma empresa que se concentra em um deles pode negociar descontos ao comprar em larga escala. Quando grandes vulnerabilidades de segurança como o Heartbleed ou o Specter são descobertas, uma maior padronização na arquitetura facilita a aplicação de correções em todos os lugares, em vez de se precisar rastrear várias equipes independentes que selecionam, implantam e atualizam versões diferentes dos sistemas operacionais no lado servidor.

Como podemos induzir esta nova estrutura em uma cultura de equipes independentes e empoderadas? Como podemos levá-los a concordar com um conjunto de tecnologias comumente usadas e que trazem benefícios para os negócios?

O Architecture Guild

Na Comcast, percebemos que esse problema era muito semelhante ao modo como os organizações de padrões abertos funcionam; ou seja, fazendo com que vários grupos autônomos concordassem com abordagens técnicas. Criamos um Architecture Guild interno, modelado com base no órgão de padronização Internet Engineering Task Force (IETF), que define vários protocolos importantes da Internet.

O IETF tem uma estrutura hierárquica com atividades distribuídas. No topo da hierarquia está o Grupo de Direção de Engenharia da Internet (IESG, em sua sigla em inglês), responsável por decidir quais áreas serão ou não abordadas pelo IETF. O IESG, por sua vez, define certas áreas temáticas como redes ou aplicativos, além de recrutar Diretores de Área (DAs) para supervisioná-los. Os Diretores de Área, por sua vez, estabelecem diretrizes para que os grupos de trabalho (GTs) definam padrões. Por sua vez, os indivíduos - e não as empresas - se juntam aos grupos de trabalho para participar do processo de redação de normas e, ao final publicam RFCs, os padrões oficiais do IETF.

No nosso caso, o papel do IESG é desempenhado por uma equipe central de arquitetura estratégica, que identifica competências técnicas específicas, na qual seria interessante ter mais padronização. Mantemos as competências onde as necessidades de nossas equipes são bem compreendidas e onde existem várias soluções maduras disponíveis; é muito mais provável que possamos encontrar uma solução adequada para a maioria dos casos nesse cenário, esperando que seja uma solução razoável por vários anos. Não estamos em uma escala que exija conceitos de Área ou do Diretor de Área do IETF, portanto, essa equipe supervisiona os grupos de trabalho diretamente.

Inicialmente, enquanto estávamos fundando o Architecture Guild, essa equipe criou muitas das diretrizes dos grupos de trabalho, embora, à medida que o Guild se consolidou, passaram a revisar com mais frequência as diretrizes dos grupos de trabalho propostas por outras equipes.

Como somos uma organização técnica distribuída, com funcionários remotos e também com escritórios geograficamente dispersos, decidimos utilizar uma abordagem assíncrona escrita para trabalhar no Guild, garantindo que todos tenham a mesma oportunidade de participar. O principal artefato aqui é um canal '#architecture' dedicado, em nossa ferramenta de chat, além de uma lista de emails. Continuamos a incentivar as equipes a ter pelo menos um de seus membros cadastrado no canal e/ou na lista de discussão para estarmos atualizados com as atividades do Guia.

Ciclo de vida do grupo de trabalho

Um grupo de trabalho começa com uma diretriz: uma breve declaração de tópicos que o grupo irá - e não irá - abordar. Como as competências e práticas técnicas são interconectadas, a definição de que alguns tópicos estão fora do escopo ajuda a restringir discussões do grupo e a permitir que ele progrida.

[Clique na imagem para ampliá-la]

Uma vez definida a diretriz, criamos um canal de bate-papo dedicado, como '#arch-wg-source-control', bem como um repositório de código para o grupo de trabalho. A criação é comunicada no canal principal "#architecture", assim como na lista de discussão, para que os indivíduos interessados possam participar. Em seguida, são selecionados 2 ou 3 representantes para o grupo de trabalho, que atuarão como editores e ajudarão o grupo a continuar progredindo. Nossa experiência demonstrou que as habilidades de facilitação/intermediação são mais importantes do que a habilidade técnica para esses representantes!

Espera-se que os grupos de trabalho documentem suas recomendações como Registros de Decisão de Arquitetura (ADRs em sua sigla em inglês) [4]. Esses documentos registram:

• Contexto: que informações consideramos ao tomar essa decisão?
• Decisão: o que recomendamos?
• Fundamentação: porque fizemos essa recomendação?
• Consequências: quais são as desvantagens conhecidas?

Descobrimos que os grupos de trabalho são tentados a ir direto às decisões, porém desenvolvemos um processo mais estruturado para a construção do consenso, iniciando com a construção da seção de contexto do Registro de Decisão de Arquitetura (ADR):

1. Permitir que todos tragam seus casos de uso relevantes; documentar estes casos no ADR.
2. Identificar os principais requisitos que uma solução recomendada deve ter, por meio da discussão.
3. Permitir que qualquer pessoa proponha uma solução específica; documentar esta lista no ADR.
4. Avaliar brevemente cada solução proposta em relação aos critérios: como aborda ou não cada um deles; documentar esta informação no ADR também.

Percebemos que algumas soluções são propostas, mas ninguém quer ter o trabalho de documentar como se alinham com os critérios. Isso é uma indicação de que não havia grande suporte a essas soluções. Também percebemos que algumas soluções não atendem a critérios obrigatórios, podendo-se eliminá-las das considerações complementares (mas mantendo os detalhes da avaliação no ADR).

Finalmente, seguindo o lema da IETF, de trabalhar com "código executável", seguimos uma regra geral: de que só podemos recomendar uma solução que as equipes possam usar imediatamente. Isso nos impede de considerar soluções "perfeitas" que ainda não foram criadas, ou soluções não comerciais para as quais ainda não temos contrato de licenciamento.

Tudo isso restringe a discussão do grupo de trabalho a um número menor de soluções viáveis. A partir desse ponto, pesquisamos o sentimento do grupo sobre as decisões. Votamos ("qual solução devemos escolher?") e também pedimos para os participantes avaliarem cada solução individualmente, de acordo com os seguintes critérios [5]

5. É a melhor solução de todos os tempos.
6. É a melhor opção do que temos disponível.
7. Não é a minha primeira escolha, mas compreendo as vantagens e eu estaria disposto a aceitá-la
8. Pode funcionar, mas precisaríamos resolver certos problemas primeiro.
9. Isso seria um grande erro.

[Clique na imagem para ampliá-la]

O objetivo, então, é encontrar uma solução que a maioria dos participantes classifique com nota 3 ou mais (ou seja, "aceitável"). Para casos em que os participantes classificaram como 2, pedimos que documentassem suas observações como questões no repositório de ADRs. A partir daqui, o grupo de trabalho pode fazer pesquisas adicionais para documentar como a observação poderia (ou às vezes não poderia) ser abordada em uma solução específica. Conseguimos mover alguns votos da pontuação "2" para pontuação "3" por meio desse processo. Às vezes, observações surgem (como de esperar) a partir do desconhecimento de uma solução proposta, e comentários de alguém mais experiente muitas vezes pode esclarecer essas questões.

A etapa final (importante) depois de se chegar a uma solução, é garantir que foram capturados os problemas conhecidos que não foi possível resolver na seção de consequências do ADR. Como sabemos, todas as soluções têm pontos negativos, e descobrimos que capturar desvantagens legítimas identificados pelo grupo de trabalho também é uma forma de se obter suporte para a decisão final. Isso porque esses membros podem ver que suas observações foram consideradas, validadas e incorporadas.

Benefícios emergentes

Desde o estabelecimento do Architecture Guild, encontramos vários benefícios que não havíamos previsto:

1. O surgimento de uma comunidade de arquitetura e de projeto
2. Aceleração da tomada de decisões
3. Colaboração coletiva das diretivas do grupo de trabalho

Nosso canal de chat #architecture começou como local para divulgação de formação do grupo de trabalho e o seu progresso, porém rapidamente se transformou em uma central de informações que traz informações para apoiar equipes em decisões técnicas. As equipes se interessam em saber quais tecnologias estão sendo usadas por outras equipes da empresa, o que permite que identifiquem, em comunidades internas de especialistas, quem poderia ajudar com problemas comuns. O canal tem agora mais de 800 membros, o que representa bem a nossa comunidade técnica interna global. São os "800 amigos mais próximos" mencionados no título deste artigo.

[Clique na imagem para ampliá-la]

Constatamos também que, uma vez tomadas as decisões do grupo de trabalho em determinadas áreas, acelerou-se a tomada de decisões em outras áreas. Por exemplo, nosso grupo de trabalho de Controle de Código-Fonte recomendou uma estratégia específica de gerenciamento de versões; O grupo de Entrega Contínua pôde se basear nessa escolha ao explorar ferramentas de integração contínua, sem precisar se preocupar com uma solução que suportasse todas as possíveis técnicas de gerenciamento de versão.

Finalmente (e especialmente animador) os participantes do Architecture Guild começaram a propor diretrizes para novos grupos de trabalho, sem esperar que o comitê diretor os propusesse. Trata-se de um ótimo indicador da aceitação de nossa equipe técnica para o processo do Guild, bem como sua compreensão da necessidade de tomar decisões comuns em certas áreas.

Conclusões

Mesmo em uma organização técnica moderna, que autoriza as equipes a tomar suas próprias decisões tecnológicas, é necessário desenvolver uma estrutura técnica comum para aproveitar o potencial que isso pode trazer, especialmente em grandes organizações. Nesse contexto, tivemos bastante sucesso construindo consensos através de uma estrutura de Architecture Guild, modelada com base em padrões distribuídos bem-sucedidos. Os grupos de trabalho, por meio de um processo inclusivo e colaborativo, produziram recomendações técnicas que passaram por análise detalhada, sendo decididas criteriosamente e com suporte amplo das equipes.

Referências:

• [1] Spors, K. "Pushing Down Decision Making in the Workplace." The Wall Street Journal. 27 October 2008.
• [2] Blakeman, C. "Why Self-Managed Teams Are the Future of Business." Inc. 25 November 2014.
• [3] Bernoff, J. and T. Schadler. "Empowered: Unleash Your Employees, Energize Your Customers, and Transform your Business". Harvard Business Review Press. 2010.
• [4] Nygard, M. "Documenting Architecture Decisions", 15 November 2011.
• [5] Calabrese, Jake. "Learning with Fist of Five Voting", 23 September 2014.
• [6] Beck et al. Manifesto for Agile Software Development. 13 February 2001.

Sobre o Autor

Jon Moore é Arquiteto de Software Chefe da Comcast Cable, onde se concentra em fornecer um conjunto de componentes de software escaláveis, robustos e de alto desempenho para os diversos grupos de desenvolvimento da empresa. Especializa-se na "arte do possível", encontrando maneiras de coordenar soluções de trabalho para problemas complexos e entregá-las no prazo. Está igualmente confortável liderando e gerenciando equipes, e desenvolvendo pessoalmente código-fonte para produção.