O que seus pipelines dizem sobre sua estrutura organizacional

Uma das "leis" associadas ao DevOps pertence a um programador chamado Melvin Conway. Sua lei foi introduzida em 1967 e simplesmente afirma que "organizações que projetam sistemas... são obrigadas a produzir projetos que sejam cópias das estruturas de comunicação dessas organizações".

Enfatizei a palavra "sistemas" porque muitas vezes a Lei de Conway é aplicada apenas a aplicativos. Para sistemas de software. Mas a realidade é que os "sistemas" abrangem tudo, desde aplicativos até os pipelines integrados que os entregam e implantam. Seus oleodutos.

Quando falamos sobre adotar metodologias DevOps no lado da implantação (produção), precisamos também estar cientes dos princípios associados, como a Lei de Conway. Porque essa lei se aplica ao design de pipelines de implantação da mesma forma que aos aplicativos que são lançados no mercado.

Você deve se lembrar de duas perguntas do nosso relatório State of Application Services de 2019. O primeiro perguntou sobre a estrutura organizacional de TI - operações combinadas, funções únicas ou equipes multifuncionais. Descobrimos que quase metade (46%) dos mais de 2.000 entrevistados estavam organizados como equipes de função única. As operações combinadas ficaram em um respeitável segundo lugar, com 37%. Equipes multifuncionais são menos comuns, com apenas 15% dos entrevistados operando em tais estruturas.

Agora isso é importante à medida que passamos a examinar o estado da automação do pipeline de implantação. Porque os resultados são definitivamente um reflexo do domínio de equipes de função única.

Os dados aqui mostram um esforço de automação inconsistente que não ajudará a atingir o objetivo de quase metade (48%) dos entrevistados com relação à transformação digital: implantar aplicativos com mais rapidez e frequência. A disparidade entre esses domínios estabelecidos dentro da TI é uma prova existencial de que a Lei de Conway se aplica a qualquer sistema, em qualquer lugar.

Analisando mais a fundo, descobrimos que pouco mais de um em cada dez (11%) automatizou apenas um desses domínios. Um em cada quatro (25%) conseguiu automatizar dois ou três domínios. E pouco mais de um em cada cinco (21%) automatizou todos os quatro domínios primários necessários para concluir um pipeline de implantação totalmente automatizado.

Uma porcentagem significativa - 42% - automatizou exatamente ZERO desses domínios.

A desigualdade da automação no pipeline de implantação é uma parte importante do quebra-cabeça do tempo para valor, porque cada vez que você encontra um processo manual no pipeline, você incorre em um atraso. Esse atraso retarda o tempo de valorização (ou tempo de comercialização, se preferir). As diferenças nas taxas mostram o impacto das organizações permanecerem em uma "estrutura de equipe de função única" porque estamos vendo "silos" individuais automatizados com pouca ou nenhuma preocupação sobre como eles interagem com o resto do pipeline.

É por isso que operações combinadas ou estruturas de equipes multifuncionais são preferidas. Porque os canais de comunicação entre domínios de TI se tornam um processo de pares que facilita melhor o design de um sistema que abrange múltiplas preocupações. Quando um pipeline (sistema) é projetado por uma equipe, eles conseguem levar em consideração o pipeline como um todo, e não apenas suas partes compostas.

O trabalho de automação em si pode ser (e provavelmente deve ser) realizado por especialistas no assunto. Mas os métodos gerais de design e integração (APIs) precisam ser projetados em uma equipe aberta e colaborativa. Caso contrário, acabaremos com silos de automação que podem ou não atender ao objetivo comercial de chegar ao mercado com mais rapidez e frequência.

Então, se você estiver enfrentando atrasos ou desvios em suas tentativas de automatizar os pipelines de produção, dê um passo para trás e considere as estruturas organizacionais existentes e como elas impactam o design desse pipeline. Você pode descobrir que, antes de poder automatizar qualquer coisa de forma eficaz, é preciso pressionar por estruturas organizacionais mais eficazes para dar suporte ao esforço.