Você é a barreira para inovação?

Nossa indústria é marcada por mudanças constantes. Entretanto, mudar é difícil - especialmente quando um sistema e um conjunto de ferramentas sólidas satisfazem as necessidades do cliente e os objetivos do negócio estão estabelecidos. Assim como uma empresa procura entrar em novos mercados ou estar no mesmo lugar que o cliente, os limites de sua estrutura atual estarão em evidência. "Mas adotamos uma estrutura flexível quando mudamos para uma abordagem N-tier. SOA supostamente permite uma flexibilidade enorme. Como saberemos que adotando microservices não estaremos regredindo cinco anos?".

Nos negócios, especialmente no ritmo acelerado dos dias de hoje e na crescente dependência tecnológica mundial, existem muitas indicações e sinais misturados sobre o assunto. No diagnóstico geral a "velha guarda", especialmente a TI, é difícil de mudar. Inúmeras reuniões com ideias fantásticas e potenciais abordagens para o sucesso são instantaneamente descartadas quando alguém percebe o tamanho do esforço que seria para engajar a equipe de TI.

Equipes tradicionais de TI detém maior parte do conhecimento sobre seu sistema, o que lhes dá uma enorme autonomia e respeito sobre a camada tecnológica. Se a TI não aderir a mudança, ela simplesmente não acontece. Criando uma barreira intransponível para a inovação.

De onde isso vem? A experiência mostra que as melhores pessoas de TI são avessas ao risco e resistentes à mudança porque sua primeira prioridade é manter tudo funcionando como deveria. Entretanto, a tecnologia avança muito rápido e muitas equipes de TI se viram empurradas por essa rápida mudança. A habilidade de receber as mudanças e ainda manter as coisas funcionando é normalmente determinada pela natureza da instituição a ser servida.

Muitas equipes de TI foram incendiadas pelos caprichos da alta administração, que esperam que eles não apenas tenham conhecimento de especialistas em praticamente todas as tecnologias do mercado, mas também mantenham os dados fluindo, não importa o que aconteça. Nenhuma reunião de vendedores técnicos está completa sem um Ops experiente no canto, adaptando seus termos sobre o processo e explicando como cada nova tecnologia irá adicionar carga ao sistema.

As organizações são como barcos - as menores podem ser ágeis e mudar rapidamente de rumo conforme necessário, sem muita complicação. As maiores, são como os navios de cruzeiro, não podem mudar a qualquer instante. Elas exigem pouca energia e um planejamento avançado para fazer mudanças radicais em seu curso. A ideia é conservar o momento de atrito com a água. Mudar de rumo a velocidades alucinantes é difícil para a organização, assim como acontece com as pessoas, pode causar um efeito chicote. Contudo, em ambos os cenários, as mudanças constantes no rumo ainda devem ser factíveis e confortáveis.

Uma grande parte do que constitui a água (e seu atrito) na minha metáfora é simplesmente cultura - a cultura da empresa como um todo, bem como as subculturas que funcionam dentro dela.

Por exemplo, as pessoas de operações são resistentes a mudanças porque não são julgadas pela inovação, mas por seu desempenho e tempo de atividade. Isso promove uma cultura que valoriza o status quo acima de tudo. Essa realidade muda para os desenvolvedores, sua cultura está cada vez mais preocupada em quebrar as estruturas. O que não é necessariamente ruim: isso incentiva testes robustos e melhor código de produção. Mas lançados em novos requisitos de negócios e/ou prazos apertados, a resistência à mudança se intensifica, mesmo entre os desenvolvedores que já estiveram livres de restrições ou regras das organizações. Às vezes, é melhor ficar com o que é seguro e evitar inovações que possam introduzir riscos.

A aversão ao risco é incorporada em uma cultura e muitas vezes refletida na estrutura, nos valores não falados e nas arquiteturas que a suportam. Essas arquiteturas são altamente redundantes, muitas vezes mantidas em datacenters controlados pela organização, monitoradas até uma polegada de vida (o que também pode levar à tarefa interminável de espremer cada grama de desempenho) e protegidas por camadas de segurança e abstração. O objetivo é a estabilidade, mas seu preço é a estagnação.

O medo da complexidade adicional também leva à aversão ao risco de testar novas tecnologias, mesmo para projetos pequenos e não críticos. Frequentemente, esses projetos podem se transformar em partes essenciais de funcionalidades que outros sistemas confiam. Uma organização com uma mentalidade ágil isolará esses sistemas e abstrairá sua funcionalidade por trás de uma API, mas as operações de TI tradicionais prefeririam evitá-los completamente, pois exigem dependências de conhecimento que complicam o processo de contratação e aumentam a lista de especialidades que a equipe deve saber. Isso geralmente leva à contorção dos sistemas atuais e das linguagens de programação para atender as necessidades para as quais não foram projetados e nem adequados para a tarefa em questão, como executar um applet Java a partir de um script cron para rotacionar os logs.

Quando o mercado muda, essas arquiteturas levam mais tempo, esforço e custo para serem desvendadas. Vimos líderes em vários setores ficarem atrás de concorrentes mais ágeis por causa das camadas de aversão ao risco acumuladas ao longo dos anos (e ironicamente destinados a manter vantagem competitiva) em sistemas e atitudes. Essa é a essência da interrupção.

Não há uma arquitetura única que possa ser adotada para resolver isso. Ao longo dos anos, as arquiteturas N-tier desmembraram mainframes monolíticos e introduziram redundância e escalonamento em nível de aplicativo e dados, além de arquiteturas orientadas a serviços, que abordaram os desafios introduzidos pelas bases de código distribuídas.

Hoje, os microservices e arquiteturas de "função como serviço", como os promovidos pelo AWS Lambda, são saudados como a solução definitiva, e organizações dedicadas seguiram a multidão aplicando esses princípios em seus próprios sistemas.

Esta é uma forma de "carga de cultura" - tomando o que parecem ser as melhores práticas adotadas pelas empresas mais ágeis e aplicando-as cegamente, na esperança de capturar algumas dessas mesmas magias. Na melhor das hipóteses, ajuda a mover a agulha um pouco. Na pior das hipóteses, isso torna o ambiente de trabalho mais hostil à medida que as organizações substituem um conjunto de práticas rígidas por outras, muitas vezes adotando os princípios sem compreender totalmente seu objetivo ou como se encaixam nas necessidades específicas da organização.

As melhores organizações são aquelas que tornam a agilidade um valor e objetivo fundamental. As decisões não são tomadas com base em se isso vai ajudar a conquistar um mercado agora, mas com um olho no que pode vir a seguir. Em vez de tentar prever o futuro, é melhor jogar um jogo resumido de "e se" em uma base consistente.

E se, por exemplo, wearables fizerem um retorno estrondoso? O que isso significaria para o seu negócio? Onde seriam as oportunidades? Como sua arquitetura atual lidaria com isso? O que você precisa fazer para chegar lá?

Com boas razões, frequentemente crio APIs como resposta para isso. APIs bem projetadas e bem gerenciadas que são dissociadas de casos de uso específicos, operam independentemente umas das outras e podem escalonar individualmente para ajudar a criar um ambiente de acesso a dados que pode se adaptar rapidamente às novas tecnologias conforme elas surgem. Mas as APIs são uma camada fina no topo do sistema maior que, em última análise, determina o sucesso.

Muitas vezes a cultura dita regras mais forte que a tecnologia. O sucesso é recompensado e o fracasso é punido? Uma perspectiva mais ágil seria aquela que celebra os sucessos, analisa os fracassos e exige que a organização dê uma olhada crítica em cada um deles, a fim de derivar aprendizados que possam ajudar a impulsionar toda a organização. Isso também significa ser um pouco indulgente se puder fornecer apenas 99% de tempo de atividade contra 99.99999% e projetar seu sistema para lidar com esse tempo de inatividade de maneira elegante.

Isso é diferente do mantra inicial do Facebook, "Mova-se rapidamente e quebre as coisas" - algo que eles abandonaram quase tão logo eles se tornaram públicos. Sempre foi um mantra imprudente que eles só seguiram parcialmente. Em vez disso, recomendo: "Mova-se deliberadamente, abrace-se e aprenda com seus fracassos". Não é tão cativante, mas uma maneira mais realista de operar que gera crescimento e aprendizado em seus processos de desenvolvimento e implantação.

A TI ainda deve priorizar a otimização do desempenho e o tempo de atividade para aqueles que dependem deles. Ninguém quer ser o elo fraco na cadeia de colaboradores que ajudam a impulsionar o sucesso corporativo. Mas isso também significa fornecer uma arquitetura que falha elegantemente e se recupera rapidamente, ao mesmo tempo em que oferece o máximo possível de informações sobre seu desempenho.

Este é um dos principais benefícios da adoção de uma arquitetura de microservices. Ao dividir sua base de código e serviços em vários pequenos aplicativos independentes que se comunicam por meio de serviços, está reduzindo o risco de que uma pequena falha possa derrubar toda a casa. Você também precisa estar atento a interconexões rígidas entre serviços que podem levar a falhas sequenciais.

Cada microservice não deve ser responsável apenas por sua área de controle, ele também deve ser projetado para falhar normalmente quando um serviço falha. Isso pode significar armazenar os dados em processo em algum lugar para recuperação rápida quando o serviço com falha estiver on-line novamente (como em um keystore como o Redis); fornecer mensagens de erro que permitam que o usuário final tome atitude (por exemplo, explicando como corrigir o problema ou passando para a equipe de suporte); monitorar ativamente os problemas de desempenho e alertar as equipes certas quando elas surgirem ("DevOps" implica que os desenvolvedores também estão de plantão); e registrando todas as informações relevantes para que elas possam ser rapidamente recuperadas e revisadas (seguir um registro em execução não é mais suficiente - se é que realmente foi).

Se está preso a um sistema legado por anos de aversão institucionalizada ao risco, ainda há esperança. Ferramentas modernas de ESB podem ajudar abstrair o monolito em serviços individuais, mitigar falhas e permitir que seu sistema seja degradado de maneira elegante. Usando essas ferramentas, é possível começar a identificar os sistemas problemáticos, substituir e modernizar conforme necessário, sem gastar muito tempo reescrevendo completamente todo o sistema.

Em paralelo, todos os novos desenvolvimentos podem adotar paradigmas mais ágeis, como arquiteturas de microservices que se comunicam por meio das APIs de serviços da web modernas. A função de operações tradicionais deve passar do cauteloso gatekeeper para um provedor de serviços centrado no cliente, com os principais clientes sendo suas próprias equipes internas de desenvolvimento. Em um ambiente DevOps real, o ônus de obter conhecimento sobre esses sistemas deve ser compartilhado entre todas as partes interessadas técnicas.

Não se deve esperar que ninguém seja um especialista total em apenas uma ou poucas tecnologias - espera-se que todos compreendam, pelo menos, o básico de todas as tecnologias que impulsionam seu sistema, talvez obtendo uma especialização de alto nível em algumas poucas peças essenciais. Considerando um programador de Java em vez de apenas um "programador", por exemplo, não se surpreenda quando tiver dificuldades para crescer em sua carreira.

A mudança é boa, mas precisa ser moderada pelos objetivos do negócio e pela realidade de seus ativos. Simplesmente adotar táticas ágeis populares não é suficiente - deve adaptar sua cultura e encontrar um modelo de agilidade que melhor funcione para sua organização. Quanto mais esperar, maior o risco de ser usurpado por alguém mais rápido.

A mudança positiva pode começar do topo ou da primavera de uma equipe de desenvolvimento. Mas, para estimulá-lo, é necessário garantir rapidamente a adesão de todos e construir uma cultura que trate o fracasso e o sucesso como oportunidades iguais de aprendizado. Faça disso um hábito adotado em toda a organização e o sucesso a longo prazo está garantido.

Também não faz mal dar uma boa olhada no espelho e garantir não se tornem o albatroz proverbial. Considere o que poderia ser e por que não é - mas suspenda todas as justificativas reflexivas sobre custos potenciais, caos e calamidade. Pergunte a si mesmo: "Eu sou a barreira para a inovação?"

Sobre o autor

Em seu papel como Diretor Global de Estratégia de Plataforma Digital, Robert Zazueta fornece consultoria estratégica, orientação e liderança de pensamento em torno da transformação digital para a TIBCO e seus clientes. Com mais de 15 anos de experiência em desenvolvimento web e quatro anos no desenvolvimento de negócios, ele desenvolveu, projetou, consumiu, suportou e gerenciou uma variedade de APIs e integrações com parceiros. Ele também mantém o NARWHL.com, que descreve uma estrutura de design para criar APIs adaptáveis.