DevOps: ficar somente nas ferramentas é caminho certo para o fracasso.

Recentemente li artigo muito interessante na Fast Company abordando a transformação na maneira de desenvolver e entregar código em um dos softwares ícones do modelo monolítico, o Microsoft Office. O artigo, “The future of Microsoft Office: Many Apps, Many Interfaces, Many Devices” mostra a transformação em curso de um imenso software monolítico agrupados em quatro aplicações (Word, Excel, PowerPoint e email), em uso por mais de 1,2 bilhão de usuários,  para uma nova arquitetura baseada em componentes, permitindo que os usuários misturem as funcionalidades como queiram, sem ter que baixar o conjunto inteiro. Além disso seu modelo de desktop com interface, orientado a teclado e mouse se transformará em apps, operando em nuvem, orientado pelo conceito de assistente pessoal. O modelo de interface passa de passivo, à espera de teclado do usuário, para conversacional, usando o Cortana, onde agentes entendem determinada ação, coletam mais informações sobre uma futura reunião, por exemplo e enviam alertas e documentação para todos envolvidos, sem necessidade do usuário explicitar isso. Uma mudança significativa por trás disso será sua maneira de entregar código. A suíte Office era entregue como “software in a box”, com novas versões a cada 2 ou 3 anos. Passará a ter entregas rápidas, semanais. O que muda? De monolítico a componentes, de teclado e mouse, a apps, de “on-premise” para nuvem e de passivo para interface pró-ativo. Na base disso um modelo de entregas rápidas.

O que este artigo nos mostra? Se um software imenso como Office (que em 2006 era estimado em 30 milhões de linhas de código), com seu código espaguete, pode ser transformado em componentes, usando-se o modelo de entrega rápida, porque não fazer dessa forma em sistemas legados nas empresas? Claro, a Microsoft terá que reescrever todo o código, que demandará muito tempo e investimento, mas no fim do túnel terá condições de competir em um novo mundo dominado por mobilidade e apps. Código teclado, mouse e software monolítico serão relíquias. Reescrever e desenhar nova arquitetura não é barato, mas à medida que cada empresa se torna uma empresa de tecnologia seus sistemas e dados passam a constituir seus principais ativos. Uma recente pesquisa mundial em um setor com imenso código legado, medido em dezenas de milhões de linhas de código, como os bancos, mostrou que em cinco anos, 80% dos principais bancos globais reescreverão seus “core systems”.

De maneira geral, na grande maioria das empresas, os processos de criação de sistemas são extremamente burocráticos. Desenha-se a solução, congela-se as mudanças durante o rollout e o sistema é entregue muitos meses após sua concepção original. São inumeráveis linhas de código, testadas por equipes separadas dos desenvolvedores, que precisam esperar semanas para um ambiente de teste ser preparado. Depois tudo é repassado para produção e caso algum, inevitável problema aconteça ou mudança seja necessária, todo um processo lento e burocrático é demandado para que a mudança seja ativada. As mudanças são geralmente agrupadas e implementadas de uma vez, algumas poucas vezes por ano. Enquanto isso, empresas como Facebook liberam milhões de linhas de código e implementam centenas de pequenas mudanças em seus sistemas diariamente, sem downtimes. Um Facebook fora do ar gera um prejuízo incalculável. Amazon libera um novo pedaço de código a cada dez segundos e atualizam 10.000 servidores de uma única vez e podem fazer um roll back com um único comando. Amazon é com certeza um varejista bem maior que a maioria dos varejistas brasileiros.

Já começamos a ver movimentos significativos no mundo todo em busca de maior agilidade na criação de software. Um exemplo que vale a pena estudar é o do desenvolvimento de um novo sistema por  uma agência governamental na Dinamarca,  publicado pela McKinsey. O estudo é “From waterfall to agile: How a public agency launched new digital services”. Observem que o exemplo deixa claro que DevOps é uma mudança cultural que vai além de tecnologia. É uma mudança no modelo mental a que estamos acostumados em TI.

Opa, entramos em uma área interessante: mudança cultural. DevOps é um movimento cultural combinado com tecnologia e processos de desenvolvimento ágeis. Sem estes três, e principalmente sem mudança cultural simplesmente DevOps não frutifica. Ferramentas de software sozinhas não criam um ambiente colaborativo, que é essencial ao movimento. DevOps é uma quebra de paradigma na cultura organizacional, tão entranhada nas áreas de TI.

Mas, o que é cultura organizacional? Este conceito foi desenvolvido em meados do século passado pelo pesquisador Edgar Shein, do MIT Sloan, em seu livro “Organizational Culture and Leadership”. A ideia básica é que um grupo de pessoas trabalhando em conjunto em uma organização pode criar uma cultura distinta da sociedade ao seu redor. Temos claros exemplos de empresas com forte cultura organizacional como IBM e outras. A cultura organizacional significa que as pessoas inseridas nela compartilham valores e comportamentos próprios.

DevOps é uma mudança cultural e não apenas aquisição e uso de ferramentas e adoção forçada de novos processos. Se não houver um movimento de mudança cultural DevOps fracassa. Simples assim.

Quais são as características culturais que propiciam um ambiente DevOps florescer? Primeiro, comunicação aberta e franca. DevOps tem muita discussão e debate. Uma organização hierárquica, com chefias ditatoriais não consegue implementar DevOps. Se o foco das discussões for conduzida por ego, poder e posição hierárquica, esqueça. DevOps não decola.

Outra mudança: responsabilidade e incentivo. Isso significa confiança que a equipe está atuando com o mesmo propósito e ninguém, em princípio, está fazendo “corpo mole”. Se estiver, será rapidamente identificado e expelido. Os elogios não são porque alguém escreveu mais linhas de código que outro e a operação não é punida porque o sistema saiu do ar.  Mas todos são todos igualmente responsáveis pelos erros e acertos. Trabalho em equipe, colaborativo.

Este modelo colide muitas vezes com a cultura entranhada em muitas empresas e consequentemente nas suas áreas de TI, com hierarquias rígidas, processos isolados e desconfiança mútua entre desenvolvimento e operação.

O desafio de implementar DevOps não é selecionar essa ou aquela tecnologia, mas motivar o setor de TI a se reinventar em termos de mudança cultural. O primeiro passo é a motivação para isso. Porque mudar? Sem resposta clara e comprometimento de todos com mudanças, ela simplesmente não acontece. Se TI não responde na velocidade que os negócios demandam TI tem que mudar seus processos. Em uma sociedade cada vez mais digital, software e algoritmos tornam-se cada vez mais os principais ativos das empresas. O patrocínio e a liderança da inspiração empresarial desta transformação digital, onde DevOps é peça essencial, é do CEO, com o CIO tendo o papel essencial de liderar o processo. Cito aqui uma frase do CEO da Nike, Mark Parker, que disse “We´re an innovation company. Innovation and design is at the epicenter of all we do”. E complementa “I always like to say that we focus on our potential and the distance between where we are and our potential, not the distance between us and our competition. That´s where a leader shoul be. And as you focus on that space, you´re gonna create some incredible things”. Vale a pena ver o vídeo desta entrevista, “Nike's Just Getting Going: CEO Parker”. Um processo de desenvolvimento tradicional, linear, não funciona em uma empresa focada em inovação, onde velocidade e agilidade são fundamentais.

Uma mudança cultural não acontece de um dia para o outro. Garantindo que a liderança executiva está a bordo, o próximo passo é começar com um projeto piloto. Este não pode ser nem simplista nem complexo demais. Mas deve ter importância para o negócio suficiente para que o CEO e o CIO estejam acompanhando e participando ativamente do processo. Objetivos devem ser claramente explicitados, para efeito de comparação. A mudança é para tornar TI mais responsiva. Sem métricas e objetivos como saber se ela está mais responsiva?

Toda mudança cultural passa por altos e baixos e para evitar que a mudança regrida, é necessário constante mentorização dos envolvidos. Lembrem-se, falamos de colaboração entre desenvolvimento, suporte e operação. Manter os grupos separados não vai mudar a cultura. O objetivo é, repito, através da colaboração, tecnologias e processos ágeis, criar e manter sistemas de forma muito mais rápida do que como é feito há décadas na empresa. Transformação digital significa que a própria área de TI seja transformada. Em mundo de mudanças rápidas, de exponencialidades, uma TI linear, que foi desenhada para operar na velocidade da sociedade industrial, adotando seus modelos mentais (hierarquias, setores isolados e algumas vezes antagônicos, poder representado por head count, etc.) simplesmente vai ser um peso e não alavancadora de inovações e mudanças. Portanto, adotar DevOps não é uma opção, mas mandatório. Por fim, recomendo a leitura de um livro conciso, mas de excelente conteúdo que é “Building a DevOps Culture”, de Mandi Walls. Vantagem adicional: grátis!