Há 70 anos, em agosto de 1945, o mundo entrou em uma era que ficaria marcada pelo temor da aniquilação nuclear. Este medo gerou e consolidou a Guerra Fria. Hoje, a possibilidade de um cataclisma nuclear é quase zero, mas enfrentamos novas ameaças de riscos difusos, com dimensões aumentadas por interfluências impulsionadas em grande parte pela globalização. Não vivemos mais em uma situação de equilíbrio, ameaçada por uma grande catástrofe, mas em uma situação de constante instabilidade. A instabilidade tornou-se a regra. Este cenário afeta o ambiente de negócios, potencializado por outro fator de extrema importância: a rápida evolução tecnológica. Há dez anos não existiam iPhones e tablets. O Facebook fez 11 anos, o AWS (que tornou público o conceito de cloud computing) apareceu em 2006 e a própria web tem 25 anos.

Entretanto, o modelo organizacional e de gestão das empresas foi nas últimas décadas baseado no conceito que estabilidade operacional, desenhado para resistir à mudanças. Quando estas eventualmente surgem, as empresas criam projetos estratégicos de longo prazo, que tentam incorporar todas as prováveis mudanças que estão ocorrendo. O objetivo é criar um novo modelo, também estável, que seja de longa duração. E o ciclo se repete… O modelo mental é claro: longos períodos de estabilidade, seguido por uma ruptura de grande porte, adaptação ao novo modelo e a consequente estabilização no novo contexto.

Óbvio que este modelo mental permeou as diretrizes e modelos de governança da área de TI. Seus processos e métodos refletem claramente a busca pela estabilidade e a resistência à mudanças. A própria bíblia de seu modelo de “change management”, o ITIL diz textualmente: “Goal: ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change-related incidents upon service quality, and consequently to improve the the day-to-day operations of the organization.” É uma visão de mudança lenta e gradual, muitas vezes suportadas por entraves burocráticos de extensa lista de aprovações gerenciais.

A pergunta então é: este modelo mental se sustenta em mundo onde a instabilidade torna-se a regra? Onde tempo e adaptabilidade é essencial para sobrevivência empresarial? Os processos, métodos e práticas de TI estão ajustados à velocidade das mudanças do cenário empresarial de hoje? TI está preparada para enfrentar competidores digitais que surgem inesperadamente em seu “consolidado” setor de negócios? TI está preparada para compreender que o sucesso do negócio é indistinguível do sucesso dos seus softwares?

Cada vez mais as inovações de negócios são baseadas em software e os negócios digitais movem-se muito rapidamente simplesmente porque software muda muito mais rapidamente que coisas físicas. Este contexto afeta qualquer setor de indústria. Uns já foram afetados, outros o serão em breve. Raros os que ficarão mais ou menos imunes a estas rupturas. E mesmo setores que se consideram imunes estão sujeitos a rupturas quando as fronteiras entre os próprios setores de indústria começam a desabar. A competição pode vir inesperadamente, tanto de uma empresa de software, como de empresas de um setor totalmente diverso.

É um cenário desafiador para as áreas de TI e os CIOs. Seus modelos mentais foram consolidados no espírito da estabilidade e do controle rígido, mesmo às custas da velocidade. O paradoxo da TI era velocidade versus estabilidade. E estabilidade sempre ganhava.  Este modelo mental prestigia a ideia que “rápido e barato” é impossível em uma TI organizada. Se quiser assim, faça fora…

O processo de desenvolvimento de software conhecido por waterfall é emblemático deste modelo. Não se dá nenhum passo sem a observância de estritas regras de controle. O ciclo de desenvolvimento e entrega de sistemas é medido em tempos adequados à era da estabilidade: meses ou, em alguns casos, anos. Não é adequada à uma era de instabilidade contínua.

Vamos colocar aqui um questionamento. Será que este modelo taylorista de desenvolvimento de software, com especificações rígidas e departamentalização de tarefas, tem validade no novo cenário de negócios? Atende à velocidade das mudanças contínuas que a instabilidade como regra impõe às empresas?

Há algum tempo a TI vem tentando ser mais rápida. Várias empresas conseguiram adotar processos ágeis em parte do seu ciclo de desenvolvimento. Mas, apesar deste esforço, ainda não é suficiente. A cultura de que volatilidade é um risco para TI ainda está entranhado no consciente dos profissionais que lidam com desenvolvimento e operação de software. Esta ideia está implícita na adoção de processos disciplinados como ITIL, que fizeram muito sentido em um mundo que muda mais lentamente, mas que hoje coloca em risco a capacidade de TI ser rápida.

A resposta está em um pensar diferente. Minha visão é que processos como DevOps, que rompem com este paradigma, apontam um novo caminho para o desenvolvimento de software. Em absoluto significa jogar fora ITIL, mas entender que implementar disciplinas rígidas não podem prevalecer sobre novos processos que possibilitem o desenvolvimento ágil e rápido. Quem demanda velocidade é o próprio cenário de negócios.  A solução estará no balanceamento correto da estabilidade proposta pelo ITIL e a velocidade proposta pelos métodos ágeis, entrega contínua e DevOps.

Uma mudança cultural e tanto! A ITIL controla o processo de mudanças reduzindo a frequência destas mudanças e disparando processos de controle se uma ocorrer. De maneira geral, o processo tradicional acumula as mudanças e faz entregas de uma vez, em big bangs – as famosas mudanças de releases. Esta espera é uma das causas de muitas áreas usuárias investirem (não por quererem, mas por necessidade) nas famosas iniciativas de “shadow IT”, potencializadas pela oferta de novas alternativas em nuvem, fora do alcance da rigidez de TI. Entregar tarde demais é a mesma coisa que não entregar, pois não atende à demanda do negócio: foi a solução ao problema de ontem, não ao de hoje!

DevOps tem outra visão: sua filosofia é de entrega contínua, com pequenos pedaços de código a cada vez. Considere que as mudanças no contexto de negócio acontecem tão rápido e com tanta frequência que esperar acumular todas elas é colocar em risco o negócio.

Adotar DevOps não é algo que acontece de um dia para outro. É uma mudança conceitual e de modelo mental. Demanda conhecimento de novas práticas e uso intenso de tecnologia para automatizar ao máximo o processo de desenvolvimento de software. Muitas empresas terão dificuldades maiores devido às questões regulatórias, principalmente as que atuam sem setores muito regulados. Outras com imenso legado de sistemas provavelmente manterão processos tradicionais em alguns dos seus sistemas e adotarão métodos como DevOps em sistemas “customer facing” que exploram mobilidade. Empresas do mundo da Internet já nascem desta forma: basta analisar os exemplos como Facebook, Google, Etsy, Amazon, NetFlix, Salesforce, Twitter e outras. O DevOps é seu modelo mental. Esta é uma sugestão: usá-las como benchmarks. Provavelmente a imensa maioria das empresas não serão o Facebook, mas porque não considerar estas empresas da Internet como benchmarks? Podemos aprender muito com elas e adaptar o que for possível a para realidade das nossas organizações.

O primeiro passo é reconhecer que o modelo mental atual já envelheceu. O segundo é a decisão de mudar. DevOps envolve novas práticas, como:

• Entrega contínua de novas funcionalidades, em doses pequenas;
• Uuso de equipes dedicadas, cross-functional e pequenas;
• Arquitetura loose coupling;
• Ambiente automatizado por excelência;
• Integração e testes contínuos;
• Ambiente interativo e colaborativo, com usuários, operação e desenvolvimento atuando em conjunto, sem fricções entre os setores, como vemos hoje.

A partir daí, preencher o gap de expertise, adotar tecnologias para automatizar os processos e fazer as mudanças culturais e organizacionais, lidando com as inevitáveis barreiras psicológicas (reação adversa à mudanças no status quo, descrença etc). Mas o fato é que a TI de hoje não pode mais atuar como a TI desenhada há 20 anos atrás. Simplesmente porque o mundo de hoje não é mais o que era há 20 anos!