Perguntas e respostas sobre o livro "Software - A terra do desperdício"

No livro Software Wasteland ("Software - A terra do desperdício", em tradução livre), Dave McComb discute o que está causando o desperdício no desenvolvimento de aplicações, e como visualizar o custo da mudança e tornar-se centrado em dados pode ajudar a reduzir o desperdício.

(Os leitores do InfoQ podem ler um trecho do livro em: "Software Wasteland: A Tale of Two Projects".)

O InfoQ entrevistou McComb sobre o desperdício no setor de sistemas de informações, por que a abordagem centrada em aplicações se tornou popular, o que as organizações podem fazer para visualizar seus problemas de desenvolvimento e manutenção de aplicações e como resolver os problemas, como a engenharia reversa pode ajudar a reduzir a complexidade e o que as empresas que reduziram o desperdício de software podem fazer para evitar o retrocesso.

InfoQ: Por que escreveu este livro?

Dave McComb: Me incomoda o fato de estarmos recompensando o mau comportamento no setor de Sistemas de Informações Empresariais. Quanto pior a capacidade de um integrador de sistemas ou de uma empresa de software de aplicação, mais dinheiro eles ganham, desde que consigam convencer seus clientes de que a anti-produtividade é necessária. Se conseguir convencer um cliente de que um projeto deve custar US $ 100 milhões, então terá um bom projeto com centenas de pessoas por vários anos. Se fosse amplamente sabido que tal projeto poderia ser realizado por cinco pessoas em seis meses, esse desperdício evaporaria.

InfoQ: A quem este livro é destinado?

McComb: Destina-se aos executivos envolvidos no patrocínio, seleção, e gerenciamento de projetos de sistemas empresariais. Este livro é para os clientes, para armá-los contra as práticas de desperdício que se tornaram a norma.

InfoQ: Quão ruim é a situação do desperdício no setor de Sistemas de Informação?

McComb: Há um número embaraçoso de casos em que os sistemas custam mais de 1.000 vezes o que deveriam. A maioria das pessoas já ouviu falar do Healthcare.gov. Alguns sabem que até agora o projeto custou US $ 2,1 bilhões (contra um orçamento original de US $ 93,7 milhões). Menos ainda sabem que ele poderia ter sido construído (muito melhor) por menos de US $ 1 milhão, o que é exatamente o que a HealthSherpa fez.

A Healthcare.gov acabou adotando muitos dos elementos de design que foram desenvolvidos na HealthSherpa.

O Registro Canadense de Armas de Fogo foi vendido como um projeto de US $ 2 milhões (US $ 119 milhões em custos e US $ 117 milhões em receita compensatória). Custou US $ 2 bilhões e registrou 8 milhões de armas antes de ser desativado.

A maioria das melhores histórias está no governo, em parte porque são alvos mais fáceis para as empresas que o atacam, mas também porque grande parte delas está no registro público.

As companhias privadas também pagam muito mais, e frequentemente recebem muito pouco de seus grandes projetos de aplicações de integração. Sabemos de duas grandes empresas que lançaram um projeto de integração de US $ 1 bilhão e US $ 250 milhões que acabou sem ter nada para mostrar.

Uma vez, houve uma grande discussão sobre a Nasa pagar US $ 600 por um martelo (mais tarde, pagaram US $ 15 pelo martelo e alocaram parte de suas despesas internas de R/D baseada em item, em vez de uma base por dólar que fez parecer pior do que era). Os piores excessos da contratação tradicional não chegam perto do que está se tornando rotina para a contratação de sistemas.

A maioria dos projetos de aplicações individuais é da ordem de 10 a 100 vezes mais caros do que deveriam ser. Mas, o problema é mais sistêmico do que apenas consertar um projeto de uma aplicação individual; o problema é o ecossistema em que os projetos vivem.

InfoQ: O que causou ou está causando esse desperdício?

McComb: Muitas empresas, quando perguntadas, gostariam de ser centradas em dados. Algumas até professam serem centradas em dados, mas poucas o são. O que acontece é que podem criar uma aplicação individual que seja centrada em dados (ou seja, os dados foram projetados primeiro e o processo e a funcionalidade aplicados posteriormente). Mas se criar (ou comprar) 1.000 aplicações centradas em dados, sua empresa terá 1.000 centros, o que significa nenhum centro.

O problema é que, com uma abordagem centrada na aplicação em mente, cada problema se parece com outro projeto de implementação a ser criado.

InfoQ: Por que a abordagem centrada em aplicações é tão popular?

McComb: Atribuo a existência continuada do pensamento centrado na aplicação a quatro causas:

• Hábito
• Desconhecimento
• Incentivos perversos
• Falta de disciplina

O hábito pode ser o maior motivo: as pessoas conseguem a aprovação dos sistemas e constroem há décadas a forma centrada na aplicação; os velhos hábitos são difíceis de serem eliminados. Muitas pessoas não sabem que existe um caminho diferente e, se não souber disso, não poderá mudar. A indústria de integração de sistemas e pacotes de software de aplicações infelizmente tem incentivos muito perversos. Ganham muito mais dinheiro implementando outro sistema, não importa quão ineficientemente. Por fim, muitos não percebem que isso não é algo que se compra, ou um projeto de curto prazo que se implementa. Isso requer muita disciplina durante um longo período de tempo (não muito dinheiro, mas muita continuidade). Nos estudos de caso que entrevistei para o meu próximo livro, todos levaram pelo menos cinco anos para chegar a uma arquitetura centrada em dados razoavelmente madura.

InfoQ: Em seu livro, foram exploradas abordagens para lidar com o desenvolvimento de aplicações que não deram certo, com exemplos incluindo arquitetura orientada a serviços e APIs, agilidade, nuvem, e inteligência artificial. Pode explicar por que eles não forneceram uma saída para o nosso problema?

McComb: O triste é que a maioria dessas tecnologias funciona. Mas como foram implementadas principalmente com uma mentalidade centrada em aplicações, acabaram se sabotando. O SOA centrado em dados, por exemplo, que geralmente é implementado pela criação de um "modelo de mensagem canônica", funciona muito bem. Cada um das aplicações participantes está em conformidade com o canônico e a arquitetura oferece benefícios. Minha observação é que menos de 5% das implementações de SOA foram a rota canônica. A maioria permitiu que aplicações registrassem sua API existente e terminaram essencialmente com interfaces ponto-a-ponto mediadas por um barramento.

InfoQ: O que as empresas podem fazer para visualizar o problema de desenvolvimento e manutenção de aplicações, e mudar?

McComb: A visualização mais vívida seria um dashboard com o custo de mudança por aplicação e por tipo de alteração. A IBM desenvolveu um bom ponto de partida com a "Classificação de Defeitos Ortogonais", mas pode-se começar com algo muito mais simples, como categorizar alterações por:

• Corrigir código que causa falha de execução
• Mudanças estéticas
• Adicionar ou remover campos para formulários
• Adicionar ou remover campos para bancos de dados
• Alterar restrições ou validação

Um tipo principal de mudança é ilustrado por uma empresa com a qual trabalhamos, que é a fusão de duas empresas de tamanho similar na mesma sub-indústria. Uma das duas empresas tem uma arquitetura e uma cultura centradas em dados muito maduras; a outra é uma montagem mais tradicional de centenas de sistemas de aplicações diferentes.

Talvez o tipo mais simples de alteração de sistema a ser implementado em uma aplicação seja alterar a lista suspensa de um valor enumerado. Neste caso, ambas as empresas tiveram que adicionar "Sudão do Sul" a sua lista de países. A empresa centrada em dados adicionou-a aos dados de referência e gerou novamente todos os formulários ou códigos necessários para implementá-la. Foi feito em um lugar e lançado para muitos simultaneamente como parte do impulso mensal. A outra empresa passou quase seis meses apenas encontrando todas as referências aos códigos de país e, por mais tempo do que isso, alterando todos os sistemas afetados.

Essa é talvez a mudança mais simples que pode ser feita em um conjunto de aplicações. Mais complexo é adicionar novos campos de dados e, portanto, alterar formulários, relatórios, transações, e APIs. Trabalhamos com uma Companhia de Seguros de Compensação dos Trabalhadores, que perdeu uma ação judicial que exigia que pagassem subsequentemente aos trabalhadores feridos uma parte do seguro de saúde que perderam se a lesão os fizesse perder emprego. Em um ambiente centrado em dados, isso seria uma mudança simples, provavelmente levaria várias semanas para adicionar os novos elementos de dados (quanto o seu empregador pagou pelo seu seguro de saúde), adicionar esse elemento a alguns formulários e relatórios, alterar alguns processos (verificar essas informações com o empregador), e adicionar um algoritmo para determinar quanto do seguro se tornaria parte da reivindicação (para tempo parcial, sazonal, etc). A mudança real custou vários milhões de dólares devido à complexidade dos sistemas afetados.

Como digo no livro, uma empresa que entende seu custo de mudança se tornará sábia.

InfoQ: O que ajuda as empresas a resolver o problema, e por que isso funciona?

McComb: Vimos empresas se tornarem centradas em dados e superar a atração de silos de aplicações sem tecnologia semântica, mas com certeza parece ser a maneira mais difícil de fazer isso. A espinha dorsal dessa abordagem é um modelo central, simples o suficiente para ser entendido, completo o suficiente para cobrir os conceitos compartilhados e flexível o suficiente para evoluir na empresa.

Acreditamos que a modelagem semântica e as bases de dados gráficas parecem ser a maneira mais rápida de conseguir isso.

Um modelo semântico fornece uma definição formal (legível por máquina) de todos os conceitos em um domínio. Ao contrário dos modelos conceituais tradicionais, o modelo semântico é baseado em padrões da Web e pode ser implementado diretamente. Não precisa ser traduzido em tabelas lógicas e físicas.

As empresas nativas digitais, como Google, LinkedIn, e Facebook, têm todos os seus dados principais implementados em bancos de dados gráficos (como o Google Knowledge Graph e o Facebook Open Graph).

Bancos de dados de gráficos são inerentemente mais flexíveis. Não é preciso ter todo o seu esquema definido antes do tempo (como é o caso do relacional) e toda classe não precisa ter o mesmo conjunto de propriedades. Os modelos semânticos podem ser implementados diretamente em bancos de dados de gráficos compatíveis com padrão (Triple Stores), como Allegrograph, MarkLogic, Virtuoso, Stardog, e Oracle 12g.

InfoQ: Como a engenharia reversa pode ajudar a reduzir a complexidade?

McComb: A verdade básica é que a maioria dos sistemas legados que existem tem muito pouca complexidade essencial e uma enorme quantidade de complexidade acidental. Em outras palavras, um sistema legado com 10 milhões de linhas de código provavelmente tem alguns milhares de linhas do que alguém consideraria ser um código algorítmico. Existem provavelmente dezenas de milhares, talvez centenas de milhares, de linhas de validação e lógica de restrição que poderiam ser facilmente substituídas por parâmetros e desenvolvimento orientado por modelo.

O problema é que essa complexidade trivial é marcada pelos dez milhões de linhas de sobrecarga. Overburden é o minério de baixo teor que precisa removido antes de começar a mineração a céu aberto, e parece ser uma metáfora apropriada. Se está usando um software de engenharia reversa para encontrar e isolar isso, então, fez um grande favor a si mesmo. Infelizmente, muitas vezes, a engenharia reversa é usada para ajudar a migrar de um sistema legado para um sistema legado novo.

InfoQ: Qual é o seu conselho para as organizações que reduziram o desperdício de software para prevenir sua quebra?

McComb: Nenhuma empresa que conseguiu isso quer quebrar, mas acontece com algumas. O que frequentemente acontece em uma mudança de gerenciamento ou em uma aquisição resultará em uma administração que não está ciente da economia dos sistemas de informação. Pior ainda, geralmente possuem crenças errôneas profundas, como a de que implementar soluções de pacote é sempre a coisa mais eficaz a se fazer (ocasionalmente é, mas poucos gerentes predizem com que frequência é mais caro do que a opção de construir um novo sistema, e nenhum considera a complexidade adicional para a empresa como um todo e o impacto na integração de sistemas).

A principal defesa não é técnica, mas política. É preciso comunicar o valor que as novas abordagens trazem e garantir que as pessoas estejam cientes da complexa armadilha que evitaram e correm o risco de voltar.

A abordagem centrada em dados ainda está longe do mainstream e terá muitos detratores, dentro e fora da empresa. Muitas pessoas serão ameaçadas por isso. Não será um processo tranquilo.

Sobre o autor

Dave McComb é presidente e co-fundador da Semantic Arts. A Semantic Arts é uma empresa de serviços profissionais, especializada em ajudar empresas a adotarem soluções elegantes, semânticas, e centradas em dados para suas arquiteturas corporativas. Seus clientes incluíram a Morgan Stanley, a Dun / Bradstreet, a Sentara Healthcare, a Procter / Gamble, a LexisNexis, a Goldman Sachs, a Sallie Mae, bem como uma dezena de agências estaduais e federais. Antes da Semantic Arts, McComb liderou os principais projetos de aplicação empresarial da Andersen Consulting (a parte que se tornou a Accenture) e foi pioneiro no desenvolvimento orientado por modelos na Velocity Healthcare Informatics. McComb tem quatro patentes na área de desenvolvimento orientado a modelos e além do "Software Wasteland", escreveu também o "Semantics in Business Systems"; e fala e escreve prolificamente.