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.

No mundo dos foguetes reais isso não seria possível. Como no mundo do software (quase) tudo pode, a Adobe liberou na noite de sábado a primeira versão pública (alpha) do Apollo.



Infelizmente, por enquanto, ele rodará só em Windows e MacOS. A versão Linux tá esperando um versão melhorada do Flash Player.

Curiosidade: foi só desabilitar o plugin Flash que o meu Firefox ficou bem mais comportado. Desabilitar não é o termo correto. Na verdade, instalei um add-on que impede a execução de propagandinhas e afins baseados no Flash. Pode? Um addon que barra um plugin! hehe.. Ê mundo!

Seguindo com o Apollo, d'uma forma bem simplificada: ele é um executor de programinhas. Será invisível para usuários 'normais', assim como é o Flash Player ou o Java (run time). Como ficou subentendido 2 parágrafos acima, ele será multi-plataforma. Outra característica básica: ele rodará aplicações Web (escritas em HTML, JavaScript, Ajax ou Flex) em modo off-line!

Tá aí aquela que pode ser a principal característica do Apollo: rodar RIA's (Rich Internet Applications) mesmo quando não estivermos conectados. E sem precisar de um browser também.

Aí podem perguntar: quem precisa d'um troço desses?

Well, acho que um monte de gente. Enquanto a conectividade total e sem fio não estiver disponível em cada metro quadrado de nosso planeta (Antarctica incluída), aplicações off-line farão sentido. Serão necessárias.

Hoje vejo várias áreas onde o Apollo poderia ser experimentado: Vendedores que trampam na rua, corretores de seguros, prestadores de serviços gerais (ciganos), vistoriadores de qualquer coisa, etc. Vantagem: se esses usuários, quando conectados, recebem a mesma aplicação (via browser ou não), eles serão mais produtivos. Não têm que aprender uma coisa 'off' e também como lidar com um site na web. As aplicações serão, para o usuário, a mesma coisa. Uma aplicação bem feita saberá fazer o sincronismo dos dados. O Lotus Workplace, da IBM, tem algo parecido com isso.

Para o desenvolvedor há um ganho considerável também: a interface é uma só. A mesma. O mesmíssimo código! Quanta redundância...

E uma percepção que torço para ser falsa: a Adobe tem uma bela oportunidade na mão. Mas, assim como a IBM (e seu Workplace), parece que não tá ligando muito. Se é a MS, a Google ou a Apple lançando algo parecido, veríamos mais estardalhaço.

Continuação de "SOOS :: Conexão", que é parte da série "Fumaça, Fogo e Fogaréu".

Neste penúltimo capítulo, tremendamente ajudado/influenciado pelos lançamentos da última semana, falaremos um pouco mais sobre a arquitetura do SOOS, particularmente sobre sua 'alma': os Serviços. Trataremos antes de diferenciar o SOOS de algumas propostas que existem por aí.

O SOOS tem pouco ou quase nada a ver com o WebOS, muito menos com os pioneiros que já estão disponíveis na Internet (YouOS, Goowy, DesktopTwo e GravityZoo). Essas propostas são na verdade "web desktops", que implicitamente acreditam em clientes redondamente estúpidos. Clientes no caso não são usuários, ok? Estou falando de máquinas cliente (micros, celulares etc). Eles só exigem um browser. O SOOS, como já vimos em todos os capítulos anteriores, parte de um princípio totalmente diferente: os Clientes serão muito inteligentes. Mesmo quando pequenininhos, como o Apple iPhone, por exemplo. Um browser não bastará.

Como bem lembrou o Braga em um comentário deixado no capítulo anterior, o SOOS "lembra" o Jini. O Jini era uma simpática idéia da Sun que hoje deve trilhar novos caminhos. Mas ela se prende na parte "conexão" que falamos no capítulo anterior. No SOOS, tão importante quanto a "vida em sociedade", é a capacidade de aprendizado do SOOS. E qual não foi minha surpresa (e, confesso, grande satisfação) quando vi o iPhone e todos os seus 'sensores'? Ainda não é 1% do aprendizado de verdade que espero ver num SOOS, mas já é muito mais inteligência do que aquela que vemos e suportamos em nossos celulares/iPods atuais. Mas minha maior alegria foi ver como o iPhone reforça a tendência da total Orientação a Serviços, o foco deste nosso estudo. iTunes, Google e Yahoo serão os primeiros provedores de serviços. Esperem por uma enxurrada de novos serviços e provedores tão logo o iPhone chegue ao mercado. Mas, afinal, o que é a tal "Orientação a Serviços" do nosso SO do século XXI? O que a caracterizará?


Orientação a Serviços

Surrupiei parte dos conceitos que apresento aqui de uma proposta relativamente recente chamada SOA (Service-Oriented Architecture)*. Ela trata especificamente de aplicações de uso corporativo. Mas algumas de suas sugestões fazem muito sentido em um Sistema Operacional. São elas:

• Acoplamento Fraco: praticamente não deve existir uma relação de dependência entre os serviços. Eles não devem ser "amarrados" entre si. E uma relação, quando existir, ocorrerá em "tempo de execução" (runtime). Isso facilitaria muito a adaptação do SOOS para qualquer tipo de dispositivo. É o que impede a MS, por exemplo, de colocar um mesmo SO em diferentes locais (XBox, micro, portáteis etc): tudo no Windows é "fortememente acoplado". Lembram-se que ela falava que seria impossível "desamarrar" o IE do Windows? Pois é...
• Contratos: Todo serviço possui um Contrato. Um documento com finalidade idêntica aos contratos do mundo real, ou seja: um acordo entre duas ou mais partes. O contrato de um serviço determina como, quando, onde e por quem ele (o serviço) pode ser usado. Usuários poderão ter contratos 'guarda-chuva' com provedores de serviços ou contratos específicos para cada serviço.
  
• Repositórios: Todos os serviços residirão em algum lugar na Web, em Repositórios. Todo provedor de serviços terá o seu. Um repositório será uma espécie de dotMac, devidamente anabolizado. Se parecerá um pouco com daqueles utilizados pela dupla apt / Synaptic (do Linux). Quando o usuário solicitar um serviço novo, o SOOS buscará na Web as alternativas e as apresentará (devidamente resumidas e na língua do usuário). Na verdade ele apresentará as vantagens e restrições (e preços) de cada opção - informações estas que foram obtidas nos contratos.
• Independência de Tecnologia: Os serviços serão totalmente independentes de tecnologia. Restrições existirão para alguns dispositivos - questão de bom senso. Mas, como regra geral, eles não "escolherão" uma plataforma específica. Inicialmente alguns fornecedores até tentarão amarrar seus serviços em algumas plataformas. Mas a tendência é a total independência. Até porque a grana estará nos serviços. E limitar o mercado não parece ser uma decisão muito inteligente. Quanto a loja iTunes deixaria de faturar se o software iTunes rodasse só em Macs? Mais sobre $grana$ no próximo sub-capítulo.

Cabe aqui ressaltar outra característica do SOOS citada no capítulo anterior. Toda instância do SOOS (do micro, da TV, do media player...) terá uma versão 'virtual', uma cópia integral que viverá na Web. MS, Apple e Google já trabalham em algo do tipo. Mas ainda enxergam apenas uma extensão de nossos discos rígidos. No SOOS o conceito será mais amplo. Suas 'cópias' manterão uma relacionamento perene na Web. Trocarão experiências, serviços e conteúdo. Aliás, conteúdo e serviços nunca serão redundantes. Desde que o contrato permita, todo conteúdo e todos os serviços estarão disponíveis para todos os dispositivos que tenham condições de executá-los / acessá-los.


Serviço = $grana$

A resposta para a questão que deixei no capítulo anterior é óbvia demais: A Grana estará praticamente toda nos Serviços. As versões do SOOS que não forem gratuitas justificarão seu valor pelos serviços adicionais que oferecerão de forma nativa (serviços residentes). Mas, de uma maneira geral, o SOOS acentuará uma tendência que testemunhamos há tempos: os dispositivos serão gratuitos ou serão vendidos bem abaixo de seu preço real; E os usuários viverão bombardeados por várias ofertas de serviços - em vários casos eles deverão assinar contratos de serviços (com faturamente mínimo fixado) para obter aquele determinado bem com preço 'promocional'. Nós já vemos isso a todo instante no mercado de celulares. O próprio iPhone será lançado com um modelo de negócio parecido: o valor (US$600) será condicionado à assinatura de um contrato com a operadora de celular (Cingular) com duração de 2 anos e com valor mínimo de US$ 80 mensais (ou algo parecido - ainda é só especulação de minha parte).

Existirão 3 tipos básicos de serviços quando o assunto for 'grana':

• Gratuitos (com segundas intenções): é o que a Google faz hoje. Entrega-nos (bons) serviços de graça, mas aproveitam o espaço e a oportunidade para fazer propaganda. Seus serviços que não fazem propaganda (particularmente aqueles que são instalados em nossas máquinas, como o Google Desktop) têm uma terceira intenção: nos conhecer melhor. Para personalizar ainda mais os futuros comerciais. Ou seja: raramente veremos algo 'de graça' que esteja só fazendo graça. Todos buscam grana.
  
  
• Transientes (ou temporários): são serviços que não precisam residir permamentemente em nossos micros, celulares e outros dispositivos. Existirão duas modalidades de cobrança:
  
  • Aluguel: onde é determinado um tempo de uso - 30 dias, por exemplo. Serão aplicados em serviços sazionais e/ou esporádios (declaração do imposto de renda, guia de viagens, etc).
  • Pay-per-Use: serviços de uso ainda mais esporádico ou indeterminado serão vendidos a granel e pagos por uso.
  É claro que será fácil criar modelos híbridos. Um aluguel com uma taxa mínima e os opcionais sendo vendidos por uso, por exemplo.
  
  
• Residentes (ou permanentes): equivalem às licenças de uso que compramos atualmente. Aquele serviço "viverá" (ou "morará") em nossas máquinas por tempo indeterminado. Editores de textos, planilhas eletrônicas e afins serão vendidos assim.
  

Ou pagos por uso. A flexibilidade dos serviços é bastante interessante. Creio que muita gente deixará de comprar coisas 'permanentes' e optará por pagar por uso. Faz mais sentido e para a maioria das pessoas (e empresas), será uma modalidade mais econômica. TCO (Custo Total de Propriedade, em inglês) deixará de ter a importância que tem hoje nos departamentos de TI.

Mas é importantíssimo lembrar de que não se trata de simplesmente fazer o download de um serviço. Já se compra software assim há um bom tempo. Nossos serviços serão a consolidação de uma tendência que hoje, em seus primórdios, estamos chamando de RIA (Rich Internet Applications, ou Aplicações Internet Ricas). O conceito vai evoluir um pouquinho. O browser deixará de ser um requisito para RIAs. Mas agora já entramos no tema "Interfaces". Isso já é assunto para nosso último capítulo. Semana que vem, finalmente, termina a saga do "SO do Século XXI".

Ou eu deveria dizer que começa a verdadeira saga?