Por uma série de motivos eu vivo adiando um post sobre o assunto. Mas algumas estrelas se alinharam de forma inédita, uma segunda terra foi descoberta e muitas coincidências e notícias pipocaram nos últimos dias, me obrigando a falar. Ontem eu falei sobre os possíveis "grandes" projetos do Brasil em 2007. Fiz um breve comentário (negativo) sobre nossas seguradoras. Anteontem o David Berlind (ZDNet) escreveu sobre como a Zimbra resolveu o "problema" offline. Bem, correndo o risco de parecer muito pretencioso, vou contar como o tal "problema" QUASE foi resolvido aqui no Brasil, há exatos 5 (cinco!) anos.

Por razões óbvias, omitirei nomes e razões sociais. Só vou destacar os membros do time, autores de uma (QUASE) obra-prima. Vamos lá:

O ramo de seguros foi um dos primeiros a tirar proveito da tecnologia da informação. Investimentos em mainframes e grandes sistemas eram facilmente justificados. No entanto, com o tempo, tornou-se um ramo bastante conservador. Aqui no Brasil os bancos tomaram a dianteira - se tornaram mais inovadores. As seguradoras seguiram recebendo e armazenando toneladas de informações. Num estudo da IBM (internacional), o autor diz que as seguradoras têm "muita memória e nenhuma capacidade de raciocínio". O autor está falando dos sistemas. O cenário é um pouquinho pior.

Como o investimento no passado foi muito grande, as seguradoras simplesmente não tinham como promover uma substituição em larga escala de seus sistemas legados. A onda dos grandes pacotes, ERPs e afins, não tocou as seguradoras. Fizeram mais sentido em outros ramos de atividade, caracterizados por pobres e surrados sistemas administrativos que eram desenvolvidos e mantidos internamente. A insatisfação com esses sistemas era grande, o que facilitou o giro da "roda da fortuna" de empresas como SAP, Datasul, Microsiga e similares. Não havia no mercado uma boa oferta para as seguradoras. E, por outro lado, elas pareciam bastante satisfeitas com seus sistemas.

Driblavam suas deficiências com novas e pontuais aplicações. Em uma década, depois do advento da Internet comercial, criaram uma imensa pilha de pequenos, arredios e heterogêneos sistemas. Em um dos piores cenários que testemunhei, a seguradora tinha mais de 15 aplicações que, de certa forma, faziam a mesma coisa. Quando uma regra de negócio era alterada, mais de 15 sistemas tinham que ser alterados. Tinha de tudo: Cobol, Clipper, FoxPro, Java, VB, ASP ...

Há um mínimo denominador comum para a maioria dos "remendos". Eles informatizam canais: corretores, bancos, telemarketing, sites etc. Cada novo canal ou demanda das áreas de negócios fazia brotar uma nova arquitetura. Não é fácil explicar, mas existem justificativas. A dinâmica do negócio confundiu-se com a profusão de novas tecnologias. Sempre havia uma tecnologia "mais adequada". A ausência de uma boa proposta de Arquitetura Corporativa (EA) facilitou a composição do "samba do crioulo doido" que caracteriza a área de TI de diversas empresas.

[Wow.. quanta introdução!]

Num belo dia de maio de 2002 nossa turminha foi jogada num projeto para uma seguradora. Ambição pequena seria bobagem: íamos trocar os mais de 15 sistemas por um único. Principal requisito: um ponto único para atualização das regras e parâmetros. O projeto era tão bom que justificou até mesmo o desenvolvimento de protótipos (RICOS e FUNCIONAIS) em tempo de proposta. Confrontamos as alternativas tecnológicas (Java X MS, pra variar), e provamos em diversos testes que a melhor solução era 100% Java.

Tinha ali um grande divisor - o "complicômetro" que nos remete ao "problema" citado no título do post: a aplicação deveria ser idêntica tanto em modo online quanto offline. A Zimbra, citada lá no primeiro parágrafo, "descobriu" o JavaDB (ou Derby da Apache). Um gerenciador de base de dados bem leve e quase invisível (para o usuário final). Ele não existia em 2002. Na época optamos pelo Hypersonic (ao longo do projeto novas e melhores alternativas foram pintando. Mas o conceito já estava fechado). Além do óbvio armazenamento dos dados gerados em modo offline, nosso "banquinho" seria também nosso novo sistema de arquivos. Armazenaria todo o código Java, fazendo controle de versões e coisa e tal. Os detalhes não interessam (por enquanto).

Além da autonomia quando desplugada, a aplicação tinha outro requisito fundamental: o "look & feel" deveria ser o mesmo do ambiente online. Esta foi, por um bom tempo, uma das partes mais complexas de todo o projeto. Hoje pululam por aí Apollo (Adobe) e Silverlight (MS), mas na época não tínhamos muitos facilitadores. Pattern MVC elevado em não sei qual potência, com megalitros de energético e café e muita discussão boa. Aliás, pude mostrar os desafios do projeto para muitos papas javeiros tupiniquins. Todos simplesmente adoravam o projeto, mesmo que discordassem de algumas soluções aplicadas ("substituir o ClassLoader é um pecado mortal!!!") hehe..

Antes do triste final, os créditos: tive a oportunidade de trabalhar com 3 arquitetos e 2 (duas!) analistas que foram um show de bola durante todo o projeto: Nelson Ponce de Leon, Hamilton Veríssimo, Luis Felipe Braga, Claudinha Nogueira Pott e Ariane Garé. Seria sacanagem não citar também as valiosas colaborações de Flávio Crispim (o aprendiz mais rápido que já vi), Fábio Pan (o programador mais rápido que já vi) e Adilson Somensari (o maior bebedor d'água que já vi - hehe.. brincadeirinha).

O trabalho dos 3 arquitetos merece muito destaque. Tensão criativa era aquilo ali. Muita tensão. Mas muita criatividade também. Era o tipo de projeto que cria isso naturalmente, sem forçação de barra (ou eventos de motivação - arrgh!). Meu primeiro pesar foi não ter tido tempo suficiente para aprender a lidar com mais eficiência com a porção "tensão" do processo. Mas a experiência foi inesquecível. Tanto que, agora - 5 anos depois - ainda me lembro de detalhes do projeto.

Mas uma equipe (QUASE) perfeita não é nada quando as organizações não lidam bem com projetos dessa natureza. Vários problemas "políticos" (e MUITA VAIDADE) condenaram o projeto. Não tem espaço para choramingos, mas o fato é que o projeto foi interrompido em seu ápice, após 30% do caminho percorrido. Um ativo (de software) muito bom - atual apesar da idade - tá aí, perdido no tempo e no espaço.

Pior, perdido em um momento em que ele seria muito útil no mercado de seguros. O Braga sempre diz: "Código envelhece". Concordo, mas o desenho da solução não. Era SOA (Service-Oriented Architecture) antes da sigla. Era RIA (Rich Internet Application) antes da sigla. Era "web-offline" antes da Zimbra, do Apollo e do Silverlight.

Agora que criei coragem, vou prolongar um pouco mais a história. No próximo post falo um pouco mais sobre a solução e sua possível viabilização.