Eu pagaria para ver estudos mais recentes sobre o rateio do orçamento de TI em médias e grandes empresas. Lá no já distante século passado era mais ou menos padrão a destinação de 70% ~ 80% do total das verbas para a manutenção das operações. Desconfio muito que este número esbarre hoje nos 90% ou 100%. Projetos novos e upgrades, que um dia mereceram algo entre 20% e 30% do orçamento total, atualmente ou são bancados pelas áreas de negócios ou simplesmente postergados. Não por acaso o Windows XP, por exemplo, ainda predomina em várias organizações¹. Alguns podem dizer que a nova política é reflexo da falta de confiança na organização de TI como um todo. Não estão de todo errados. Mas não tocam nas raízes do problema.

O tema começou a me chamar a atenção quando percebi que vários participantes do FAN não eram analistas de negócios (AN’s) de fato, mas luxuosos atendentes de help desk. Seu dia-a-dia não é o apoio a novos projetos mas sim o tratamento de demandas de manutenção em sistemas. Por favor, não estou dizendo que demandas de manutenção não mereçam a alocação de AN’s. Algumas poucas, que de fato representam mudanças no negócio, justificam isso. Acontece que a grande maioria delas, independente do tipo ou porte do negócio, refere-se exclusivamente aos sistemas. Pior, são fruto de sistemas de baixíssima qualidade técnica.

O imenso e incomensurável backlog de manutenção é o inferno de um sem número de departamentos de TI. Ao que tudo indica, muitos acreditaram que os AN’s representariam uma boa resposta. Caro engano. Tão dispendioso quanto aquele de um famoso instituto que registra “recomendações” numa famosa publicação tupiniquim: em um de seus últimos artigos, “ele” falou que estruturas de projeto e de manutenção não precisam ser separadas. E que tal divisão poderia resultar em acidentes. Céus!

Quando projetos e manutenção começam a concorrer pelos mesmos recursos, e dado nosso “tudo é para ontem”, é claro que a manutenção – a necessidade “indriblável” de apagar de incêndios – sempre prevalecerá. Resumindo: se a empresa nutre uma mínima preocupação com seu futuro, deveria ter uma unidade que cuide exclusivamente de novos projetos. E é aqui que os AN’s podem provar seu valor e justificar seus custos.

.:.

Mas, como antecipei lá nas categorias deste artigo, eu não quero falar apenas sobre a análise de negócios. Quero aproveitar a oportunidade para tocar n’outro tema caro e meio raro (por aqui): arquitetura. Já acreditei que SOA (Arquitetura Orientada a Serviços) era uma excelente resposta à crescente demanda por flexibilidade e agilidade. Bom, ela segue excelente. Mas está longe, muito longe de ser uma resposta universal. Muitos daqueles sistemas que conhecemos como “legados” são tão feios, frágeis e gambiarrados que impedem que o “botox” SOA surta algum efeito. Daí que de uns tempos pra cá resolvi ressuscitar um conselho daquele mesmo instituto que critiquei acima: “aposente 2 ou 3 sistemas legados por ano. Ponto.”

O conselho é anterior às ondas EAI (Enterprise Application Integration) e SOA. Mas a cada dia se torna mais necessário e urgente. O fato é que há um imenso abismo entre a arquitetura tecnológica de vários sistemas legados e as demandas atuais. A ploriferação de modernos canais digitais e a crescente pressão que eles excercem sobre aplicações antigas justificam a incorporação desse discurso de urgência. E é importante notar que não estou falando apenas de coisas de museu como Cobol², Oracle Forms, Delphi, Visual Basic, Fox ou Clipper. Tudo o que nasceu na primeira geração da Internet deve ir para o lixo. Devemos aceitar o fato de que nossos primeiros sites e aplicações Web, mesmo aqueles com “apenas” 5 ou 6 anos de vida, serviram para aprendizado. Mas hoje são pesadíssimas âncoras que impedem nossa evolução. Cada centavo gasto em sistemas antigos (feios, frágeis e gambiarrados) é centavo jogado fora. Mesmo que o centavo seja contabilizado em rubricas chiques como SOA, BPM, BI e afins.

A aposentadoria de aplicações de negócios está longe de ser uma coisa trivial. São raríssimas as empresas que utilizam um processo de gerenciamento do ciclo de vida de sistemas³. Nós desenvolvedores só falamos, através de nossas mágicas metodologias, do ciclo de vida de projetos. Pouquíssima ou nenhuma atenção é dada ao sistema entregue. Até o dia seguinte ao término do projeto, quando aquele sistema vira “legado” e um novo foco de incêndio a ser combatido diariamente.

.:.

Auren Hoffman escreveu um excelente artigo sobre “Ser Bom em Matar Coisas“. Um bom líder de TI deve saber hora e forma de matar (ou aposentar) seus sistemas. Como já falei demais, guardarei “hora e  forma” para futuros artigos. Inté!

.:.

Observações:

  1. O colega Saulo Arruda citou, num comentário lá no Graffiti, que uma grande empresa de Telco ainda demanda projetos em ASP (não .Net) com uso incondicional do Windows 2000 e IE6. Falou também de uma montadora com a mesma arquitetura. Qualquer coisa feita em ASP deveria ir para o lixo incondicionalmente. E escrever projetos novos em ASP é o mesmo que “tentar apagar incêndios com etanol”, para surrupiar e adaptar um antigo dito de Fred Brooks (utilizado em outra situação, é claro).
    Pedindo licença aos letrados, tentarei explicar aos leigos porque ASP (Active Server Pages) é uma das coisas mais medonhas e perigosas já inventadas em nossa área. Pensem num texto qualquer escrito de maneira desestruturada e acidental em três dialetos distintos, todos misturados. Três dialetos mais ou menos assim: a língua de participantes do BBB, a linguagem cifrada que a geração Y usa em sites de relacionamento mais um manuscrito original de um Jack Kerouac bêbado. ASP é assim. E na mão de programadores eXpertos vira poesia pura.
  2. Há quem diga que Cobol se modernizou. Tem também aqueles que defendem que ainda não inventamos nada para substituí-lo em grandes corporações (o que me faz pensar se Google, Amazon e afins são pequenas). De qualquer maneira, como não vejo a carinha dele (Cobol) há muito tempo, deixo a dúvida no ar.
  3. Para falar a verdade, só conheço uma proposta formal de processo que prevê o gerenciamento do ciclo de vida de sistemas. Ele atende pelo nome EUP (Enterprise Unified Process) e foi criado por Scott Ambler. Sim, podemos dizer que é um irmão bastardo (e ainda não reconhecido) do RUP.
  4. A imagem utilizada, Tändsticka, é do brandbild e foi liberada como CC-by, por isso está aqui.