Uma das “leis” associadas ao DevOps é de autoria de um programador chamado Melvin Conway. Sua lei foi apresentada em 1967 e afirma simplesmente que “as organizações que projetam sistemas... são limitadas a produzir projetos que são cópias das estruturas de comunicação dessas organizações”.
Enfatizei a palavra "sistemas" porque, com muita frequência, a Lei de Conway é aplicada apenas a aplicativos. A sistemas de software. Mas a realidade é que "sistemas" abrangem tudo, desde os aplicativos até os pipelines integrados que os entregam e implantam. Os seus pipelines.
Quando falamos em adotar metodologias DevOps na área de implantação (ou seja, em produção), também precisamos estar atentos a princípios relacionados, como a Lei de Conway. Afinal, essa lei se aplica tanto ao projeto dos pipelines de implantação quanto aos aplicativos que eles disponibilizam no mercado.
Talvez você se lembre de duas perguntas da nossa pesquisa State of Application Services de 2019. A primeira tratava da estrutura organizacional de TI: operações combinadas, equipes de função única ou equipes multifuncionais. Constatamos que quase metade (46%) dos mais de 2.000 entrevistados estava organizada em equipes de função única. As operações combinadas ficaram em um respeitável segundo lugar, com 37%. As equipes multifuncionais são menos comuns, com apenas 15% dos entrevistados trabalhando em estruturas desse tipo.
Isso é importante agora que passamos a analisar o estado da automação do pipeline de implantação, pois os resultados refletem claramente o predomínio das equipes de função única.
Os dados apresentados aqui revelam um esforço de automação inconsistente, que não ajudará a alcançar o objetivo de quase metade (48%) dos entrevistados em relação à transformação digital: implantar aplicativos com mais rapidez e frequência. A disparidade entre esses domínios consolidados da TI é uma prova concreta de que a Lei de Conway se aplica a qualquer sistema, em qualquer lugar.
Analisando mais a fundo, constatamos 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 os quatro principais domínios necessários para implementar um pipeline de implantação totalmente automatizado.
Uma porcentagem significativa — 42% — não automatizou NENHUM desses domínios.
A desigualdade da automação ao longo do pipeline de implantação é uma peça importante do quebra-cabeça do tempo de geração de valor, pois cada processo manual encontrado no pipeline provoca um atraso. Esse atraso aumenta o tempo necessário para gerar valor (ou o tempo de lançamento no mercado, se preferir). As diferenças nas taxas mostram o impacto de as organizações permanecerem em uma "estrutura de equipe de função única", pois vemos "silos" individuais sendo automatizados com pouca ou nenhuma preocupação sobre como eles interagem com o restante do pipeline.
É por isso que estruturas de operações integradas ou de equipes multifuncionais são preferíveis. Isso ocorre porque os canais de comunicação entre os domínios de TI passam a funcionar como um processo entre pares, facilitando o projeto de um sistema que abrange diversas áreas. Quando um pipeline (sistema) é projetado por uma equipe, ela consegue considerar o pipeline como um todo, em vez de tratá-lo apenas como um conjunto de partes isoladas.
O trabalho de automação em si pode ser (e provavelmente deve ser) realizado por especialistas no domínio. No entanto, o projeto geral e os métodos de integração (APIs) precisam ser definidos por uma equipe aberta e colaborativa. Caso contrário, acabamos criando silos de automação que podem ou não contribuir para o objetivo de negócio de lançar produtos no mercado com mais rapidez e frequência.
Portanto, se você estiver enfrentando atrasos ou desvios ao tentar automatizar pipelines de produção, dê um passo atrás e avalie as estruturas organizacionais existentes e como elas afetam o design desse pipeline. Talvez você descubra que, antes de conseguir automatizar qualquer coisa de forma eficaz, seja necessário promover estruturas organizacionais mais eficientes para dar suporte a esse esforço.
Sobre o autor
Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...