A fábula dos porcos assados (e os sistemas de informação)

Certa vez, aconteceu um incêndio num bosque onde havia alguns porcos, que foram assados pelo fogo. Os homens, acostumados a comer carne crua, experimentaram e acharam deliciosa a carne assada. A partir dai, toda vez que queriam comer porco assado, incendiavam um bosque.  O tempo passou, e o sistema de assar porcos continuou basicamente o mesmo.

Mas as coisas nem sempre funcionavam bem: às vezes os animais ficavam queimados demais ou parcialmente crus. As causas do fracasso do sistema, segundo os especialistas, a dos porcos, que não permaneciam onde deveriam, ou à inconstante natureza do fogo, tão difícil de controlar, ou, ainda, às árvores, excessivamente verdes, ou à umidade da terra ou ao serviço de informações meteorológicas, que não acertava o lugar, o momento e a quantidade das chuvas.

As causas eram, como se vê, difíceis de determinar – na verdade, o sistema para assar porcos era muito complexo. Fora montada uma grande estrutura: havia maquinário diversificado, indivíduos dedicados a acender o fogo e especialistas em ventos – os anemotécnicos. Havia um diretor-geral de Assamento e Alimentação Assada, um diretor de Técnicas Ígneas, um administrador-geral de Reflorestamento, uma Comissão de Treinamento Profissional em Porcologia, um Instituto Superior de Cultura e Técnicas Alimentícias e o Bureau Orientador de Reforma Igneooperativas.

Eram milhares de pessoas trabalhando na preparação dos bosques, que logo seriam incendiados. Havia especialistas estrangeiros estudando a importação das melhores árvores e sementes, fogo mais potente etc. Havia grandes instalações para manter os porcos antes do incêndio, além de mecanismos para deixá-los sair apenas no momento oportuno.

Um dia, um incendiador chamado João Bom-Senso resolveu dizer que o problema era fácil de ser resolvido – bastava, primeiramente, matar o porco escolhido, limpando e cortando adequadamente o animal, colocando-o então sobre uma armação metálica sobre brasas, até que o efeito do calor – e não as chamas – assasse a carne.

Tendo sido informado sobre as idéias do funcionário, o diretor-geral de Assamento mandou chamá-lo ao seu gabinete e disse-lhe: “Tudo o que o senhor propõe está correto, mas não funciona. Isso pode funcionar na teoria, mas na prática não faz sentido. O que o senhor faria, por exemplo, com os anemotécnicos, caso viéssemos a aplicar a sua teoria? E com os acendedores de diversas especialidades? E os especialistas em sementes? Em árvores importadas? E os desenhistas de instalações para porcos, com suas máquinas purificadoras de ar? E os conferencistas e estudiosos, que ano após ano têm trabalhado no Programa de Reforma e Melhoramentos? Que faço com eles, se a sua solução resolver tudo? Hein?.”

“Não sei”, disse João, encabulado.

“O senhor percebe agora que a sua idéia não vem ao encontro daquilo de que necessitamos? O senhor não vê que, se tudo fosse tão simples, nossos especialistas já teriam encontrado a solução há muito tempo?.”

“O senhor, com certeza, compreende que eu não posso simplesmente convocar os anemotécnicos e dizer-lhes que tudo se resume a utilizar brasinhas, sem chamas? O que o senhor espera que eu faça com os quilômetros de bosques já preparados, cujas árvores não dão frutos e nem têm folhas para dar sombra? E o que fazer com nossos engenheiros em porcopirotecnia? Vamos, diga-me!”.

“Não sei, senhor.”

“Bem, agora que o senhor conhece as dimensões do problema, não saia dizendo por aí que pode resolver tudo. O problema é bem mais sério do que o senhor imagina. Agora, entre nós, devo recomendar-lhe que não insista nessa sua idéia – isso poderia trazer problemas para o senhor no seu cargo.”

João Bom-Senso, coitado, não falou mais um “a”. Sem despedir-se, meio atordoado, meio assustado com a sua sensação de estar caminhando de cabeça para baixo, saiu de fininho e ninguém nunca mais o viu. Por isso é que até hoje se diz, quando há reuniões de Reforma e Melhoramentos, que falta o Bom-Senso.”

Desconheço o autor desta fábula, mas ainda vejo florestas sendo queimadas com muito mais frequência do que imaginaria na área de Tecnologia de Informação.

Ouvi um relato de um projeto que foi fragmentado para quatro empresas fornecedoras operando remotamente, cada um com a sua especialidade tecnológica (Mobilidade, barramento, back-end e Web). Uma desculpa para este arranjo foi que cada empresa fornecedora era “dona” de uma tecnologia e os acordos contratuais exigiam esta distribuição. Dois anos depois e com com milhões de reais gastos nenhum produto foi entregue. O diretor de assamento então resolveu assar no espeto os gerentes e algumas fábricas que participaram deste processo.

Também tive a oportunidade de ver um time de produto que herdou uma arquitetura Web absurdamente complexa de um  “arquiteto super inteligente” de uma fábrica de software. O efeito desta arquitetura é o que time demora 3 semanas para implementar um cadastro de complexidade média.

Estas histórias reais me lembram do conceito de complexidade acidental e complexidade essencial, popularizado na TI por Neal Ford.

A complexidade essencial representa a dificuldade inerente a qualquer problema. Na nossa fábula acima, acender fogo era necessário para assar os porcos.  A complexidade decorrente dos compromissos que assumimos que incorrem em dívidas técnicas é diferente. Consiste em todas as formas imposta externamente de que o software se torne complexo e não deve existir em um mundo perfeito. A isso chamamos de complexidade acidental. Tecnologias como o Java EJB, Microsoft BizTalk e ERPs cujos nomes não podem ser pronunciados são exemplos de complexidade acidental na TI.

Tomo a liberdade aqui de expandir a definição original do autor, pensada para arquiteturas de software, para arranjos essenciais e arranjos acidentais.

Por exemplo, a existência de analistas desenvolvedores, analistas de testes e líderes de projetos são arranjos essenciais para entregar software de qualidade. Já times de testes e times de desenvolvedores que trabalham em salas separadas e com processos cascatas são exemplos de arranjos acidentais. E os  “gerentes de projetos” que ficam atrás das suas mesas 8 horas por dia atualizando cronogramas Gantt de 1000 linhas e perguntando aos seus coordenados “Eh aí, tá pronto?” são exemplos também ruins de arranjos acidentais.

Se você está cansado de queimar florestas inteiras para assar porcos, recomendo a aplicação de práticas do Lean Software Development, um corpo de práticas muito legais para você descomplicar a sua TI e a forma como entrega e mantém software.

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”
Edsger W. Dijkstra

Não Alimente Seus Paquidermes

Com seu tamanho gigante, humor variável, vontade própria e dificuldades de serem domados, os paquidermes dominam o planeta terra.

Sim! É verdade.

Mas pare… não estou falando dos animais de quatro patas da ordem dos proboscídeos. Estou falando dos sistemas de informação monolíticos que assolam as organizações brasileiras.

Provavelmente você já deve ter visto algumas destas bestas. Elas podem ser reconhecidas pelas seguintes catacterísticas:

  • Bancos de dados com centenas de tabelas;
  • Centenas de telas e relatórios;
  • Repositórios de código com centenas de milhares de linhas de códigos
  • Linguagens arcaicas;
  • Enorme débito técnico;
  • Ausência de testes automatizados;
  • Baixo uso de práticas provadas de engenharia de software e DevOps.

Eles atendem por nomes como ERPs, MRP, CRMs, Portais e sistemas de informação com siglas que começam pela letra S. Na prática, estes produtos geram urgências em base semanal e tornam a vista dos seus gestores um inferno.

Para piorar a situação, muitos gestores e desenvolvedores continuam a alimentar estes paquidermes em base mensal. Eles constroem novos módulos nestes produtos. E devido ao seu tamanho e a ausência de testes automatizados, cada modificação tende a gerar efeitos colaterais que se manifestam em problemas que acontecem semanas ou meses depois da manutenção originalmente realizada.

A Lei dos Retornos Decrescentes dos Softwares

Na engenharia de software, quanto maior um sistema maior o custo de manter cada unidade deste sistema. Ou seja, se um sistema novo é duas vezes maior quem um sistema original base, ele provavelmente terá custado mais que duas vezes o custo do sistema base. E provavelemente o sistema novo terá uma complexidade ciclomática média maior que o sistema base e uma produtividade de manutenção muito ruim. Isso pode ser observado informalmente no repositório público de sistemas do SonarQube online. E para os mais céticos, recomendo a leitura dos artigos científicos publicados pelo brilhante cientista Capers Jones a respeito. Recomendo ainda o seu excelente livro de medição aplicada de software.

Em termos simples — Quanto maior o número de linhas, telas, funções e tabelas do seu sistema, pior será a sua densidade de defeitos e a complexidade ciclomática média. Mais medonho, mais feio e com maior chance de gerar problemas para você e o seu time no seu ambiente de produção.

Estrangule seus paquidermes… em 7 passos

Vamos lembrar que não estou falando dos animais de quatro patas com dentes de marfim ameaçados de extinção na África. Estou falando dos sistemas monolíticos gigantes e mal-humorados. E o padrão de estrangulamento (Strangler) já foi até documentado na literatura pelo profícuo autor Martin Fowler .

Aponto aqui algumas dicas para estrangular seus paquidermes:

  1. Comece a expor as funcionalidades existentes nos sistemas monolíticos legados através de APIs. Em linhas gerais, crie APIs que irão expor funcionalidades Cobol, PL-SQL, C, C# ou Java de uma forma governada. Devemos dar sobrevida a estes código, ao mesmo tempo que começamos a pavimentar um caminho paralelo. A respeito de APIs, apresentei algumas dicas de como iniciar a sua jornada nesse blog.
  2. Considere reduzir o tamanho dos seus novos sistemas. Mesmo que você tenha produtos de enorme porte para serem construídos, construa-os em módulos independentes e autônomos. Se possível, considere abordagem mais modernas de serviços como os microsserviços ou nanoserviços. Microsserviços são serviços autônomos com linhas de base de código reduzidas e que operam de forma autônoma com suas próprias bases de dados. Algumas das vantagens do uso deste estilo incluem:
  • Cada microsserviço é relativamente pequeno. Com isso o código é facilmente compreendido pelo desenvolvedor. A baixa quantidade de código não torna a IDE lenta, tornando os desenvolvedores mais produtivos. Além disso, cada serviço inicia muito mais rápido que uma grande aplicação monolítica. Isso torna os desenvolvedores mais produtivos e agiliza as implantações. A arquitetura de microsserviços facilita escalar o desenvolvimento. Pode-se organizar o esforço de desenvolvimento em vários times pequenos com o uso de métodos ágeis e práticas DevOps. Cada equipe é responsável pelo desenvolvimento e implantação de um único serviço ou um conjunto de serviços relacionados. E cada time pode desenvolver, implantar e escalar seus serviços, independente de todos os outros times.
  • Cada microsserviço pode ser implantado independentemente de outros serviços. Caso os desenvolvedores responsáveis por um serviço necessitem implantar uma modificação para um determinado serviço que não impacte a API deste serviço, não há necessidade de coordenação com outros desenvolvedores. Pode-se simplesmente implantar as modificações. A arquitetura de microsserviços torna viável a integração e a implantação contínua.
  • Além disso, cada microsserviço pode ser escalado de forma independente de outros serviços através da duplicação ou particionamento. Cada serviço pode ser implantado em um hardware mais adequado para as exigências de seus recursos. E tecnologias de contêineres como o Docker facilitam a gestão e isolamento de dependências tecnológicas.

3. Considere o uso de tecnologias mais simples e produtivas. Saem de cenas servidores de aplicação e Web pesados como IIS ou Websphere, ESBs, BPMS, o .NET Framework e até mesmo o Java EE full stack. Entram em cena tecnologias mais simples como .NET Core para C#, Spring Boot para Java, Node.JS e linguagens dinâmicas como Python e Javascript.

4. Melhore a maturidade de testes do seu time. Comece a automatizar testes funcionais e introduza suítes de testes de unidade nos seus novos produtos.

5. Comece a usar tecnologias de conteinerização para tomar contas dos seus novos produtos e dos paquidermes legados. Vagrant, Docker, Mesos, Kubernetes e o Rancher, entre outras tecnologias, são muito bem vindos neste novo jogo.

6. Faça benchmarking. Visite empresas na sua cidade ou estado que estão já usando esta abordagem. Aprenda com os seus erros e sucessos.

7. Tenha paciência. Você nao irá estrangular um paquiderme da TI em uma semana. Este processo tende a ser demorado e pode demorar meses ou anos. A Netflix, por exemplo, demorou aproximadamente 8 anos para migrar o seu extinto sistema paquidérmico para centenas de microsserviços que hoje dominam a sua operação em produção.

Não aumente mais a entropia da sua TI

Vamos lembrar que grandes sistemas tentem a aumentar a entropia na sua TI. E a entropia é danosa. Ela aumenta o passivo técnico, gera mais incidentes em produção e provoca efeitos sistêmicos graves em projetos como o tão comum padrão Firefighting.

Está declarada aberta a temporada de caça aos paquidermes da TI

O Gartner Group observa que, na média, empresas gastam 70% do seu orçamento de TI com atividades de sustentação. E os paquidermes infelizmente contribuem para este horroroso número. Sobra apenas 30% para atividades que ajudam a crescer e transformar o negócio. E isso ajuda a explicar o porque as áreas de negócio tem uma reputação tão ruim do nosso trabalho.

Considere se você quer manter a TI da sua empresa na média mundial de investimento ou avançar a maturidade com estrangulamento o abate dos paquidermes legados e a introdução de sistemas com arquiteturas de mais fácil construção e manutenção.