Pequeno trecho de uma provocação "profunda" do David Berlind (ZDNet):

For decades, we’ve been taught by the vendor community that we should compartmentalize our business thinking into categories that map well to their categories of solutions. While I’d rather not single out Microsoft, it’s really the classic example. If you need to create and print different kinds of documents (what business doesn’t?), you get something like Microsoft Office. If you want to collaborate with others over those documents (what business doesn’t?), you buy or subscribe to a Sharepoint server. If you need a Web presence (what business doesn’t?), you set up a Web server (or find someone else who will host it for you). Microsoft would prefer this be its Internet Information Services server.

If you’re someone who runs a business, before you know it, you’re managing all sorts of products running on all sorts of operating systems (desktop and server). With weekly security updates, annual service packs, less frequent upgrades, all sorts of crazy showstoppers that turn into mini-sink holes of time and money, vendors will tell you it’s not nearly the management and expense nightmare that it really is, especially if you buy into their management solutions. Yes, so complex are the “on-premises” solutions that you have to buy other management products just to keep the infrastructure from having a heart attack.

Are we incapable of looking in from the outside and asking if there’s a better way?

Junte isso com aquele papo de que 44% das empresas que licenciam grandes volumes de software não sabem direito o que estão comprando...

CIO's 2.0, quando surgirem, farão um belo estrago.

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.

Parece que o tema subiu nas paradas nesta semana. Teve o lançamento do Apollo, que já comentei aqui. Ontem pintou uma suspeita (bem suspeita mesmo) de que a Google estaria preparando uma versão 'off-line' de seus pacotinhos de produtividade (Docs e Spreadsheet).



Agora aparece um debate sobre o MDE (Mozilla Desktop Environment). Diferente de seus pares, ele seria totalmente baseado no browser. Um BBDE (Browser-Based Desktop Environment). Grande questão técnica: seu funcionamento offline.

Quem vive no centro dos grandes centros não vê muita utilidade nisso. Quando não está em sua rede local, está a poucos metros d'um hotspot. Minha querida Varginha tem 120k habitantes. Uma das 10 maiores arrecadações de ICMS de Minas. Um respeitável pólo industrial (Walita, Samsung...). E, se não fosse pelas 3 lan-houses no centro da cidade, ficaríamos totalmente offline quando em trânsito. Imagina o que ocorre em outros cantos menos afortunados!

Não é só por isso, mas a modalidade offline é simplesmente obrigatória. Seguirá assim pelos próximos 5 anos, no mínimo.

[A foto é do D'Arcy.]