Quem disse que DevOps e ITIL são excludentes?

Nas últimas décadas, o modelo organizacional e de gestão das empresas
foi baseado no conceito que estabilidade operacional, desenhado para
resistir às 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.

Obviamente 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 a mudanças. A própria bíblia de
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 é: o velho modelo mental se sustenta em mundo onde a
instabilidade torna-se a regra? Onde tempo e adaptabilidade são essenciais
para a sobrevivência da empresa?

Os processos, métodos e práticas de TI
estão sendo ajustados à velocidade das mudanças do cenário empresarial
de hoje? A TI está preparada para enfrentar competidores digitais que
surgem inesperadamente em seu “consolidado” setor de negócios?

A 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 serão 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 para 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 de que o “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 a era da estabilidade: meses ou em
alguns casos anos. Não é adequada a 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  tarefas específicas, 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 seu ciclo de
desenvolvimento. Mas, apesar deste esforço, ainda não tiveram sucesso. A
cultura de que volatilidade é um risco para TI ainda está entranhada no
inconsciente 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.

Devops na veia
A resposta está em um pensar
diferente. Minha visão é a de 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 pode 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 da velocidade proposta pelos métodos
ágeis, entrega contínua e DevOps.

Uma mudança cultural e tanto. 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 de cada vez. Considera 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 a 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.

DevOps é seu modelo mental. Empresas da Internet, em todo o mundo, já
nascem desta forma: basta analisar os exemplos como Facebook, Google,
Etsy, Amazon, NetFlix, Salesforce, Twitter e outras. Esta é uma
sugestão: usá-las como benchmarks. Provavelmente a imensa maioria das
empresas não serão Facebooks, mas porque não considerar estas empresas
da Internet como benchmarks? Podemos aprender muito com elas e adaptar o
que seja 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 (a) entrega contínua de novas funcionalidades, em doses
pequenas, (b) uso de equipes dedicadas, cross-functional e pequenas, (c)
arquitetura loose coupling, (d) ambiente automatizado por excelência,
(e) integração e testes contínuos e (f) 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!

(*) Cezar Taurion é head de Digital Transformation da Kick Ventures e
autor de nove livros sobre Transformação Digital, Inovação, Open
Source, Cloud Computing e Big Data