It has become clear to me that SOA is not working in most organizations.
...
The techies just can’t sell SOA to the business. They have yet to demonstrate how all this infrastructure yields any business value.

- Anne Thomas Manes

Dona Anne confirma aquele que era meu maior temor quando publiquei meu primeiro estudo sobre SOA: TI colocando sua cara e morosa carroça na frente do mansobovino negócio. Como canta o Pearl Jam (em "Crazy Mary"), "That WHAT you fear the most, could meet you halfway".

Até quando TI seguirá, SISTEMATICAMENTE, matando boas novas?

No início do século a vítima foi CRM (Customer Relationship Management). Apesar de centenas de avisos, muitos saíram torrando tufa$ em ferramentinhas que meses antes eram só SFA (Sales Force Automation) ou só uma aplicação(zinha) de help-desk. Como li num lugar esquecido, "'animais' que foram marcados (a ferro) com a sigla da moda, CRM". Resultado: 80% de projetos fracassados.

Agora é SOA que pasta sem gerar a "energia" requerida pelo bovinomanso negócio. Começaram onde? Licenciando ESB's (Enterprise Service Bus), com certeza. E fingindo (ou pretendendo) que aquele amontoado de Web Services é sinônimo de arquitetura. Tsc, tsc...

Empresas sérias começarão a proibir que a área de TI tenha qualquer tipo de iniciativa. Mesmo que seja um happy-hour, amigo-oculto ou um churrasquinho no final de semana. É que começarão pelo orçamento e pelas ferramentas e tecnologias, esquecendo-se do essencial. Do negócio!

Uma cara tá bem documentada no Flashback do mês. Desatualizada? Então saca só um trecho de um anúncio de um evento tupiniquim sobre SOA:

Em um mercado feito de buzzwords, a palavra da vez é SOA. Nos últimos anos, a popularidade da arquitetura orientada a serviços cresceu dramaticamente e as taxas de adoção também vêm aumentando significativamente. Localização geográfica, porte ou segmento de atuação não interferem, todos querem SOA.

Os negritos não são meus!

A cara tupiniquim tá com uns 2 anos de atraso. Cágados míopes e mancos? Pode ser. Resta torcer para que não repitam o caminho que o Zapthink acaba de comentar em "Who's Killing SOA?". Saca só o trechinho sobre CIO's:

You'd think that every CIO would be all over SOA. After all SOA can reduce integration cost, increase business visibility and agility, increase asset reuse, and ease regulatory compliance. What's not to love? For any organization that faces any or all of these problems, SOA is a no-brainer. And yet, the CIO is rarely the SOA champion for the IT organization.

The reasons for this lack of insight are many and varied. Many CIOs are nontechnical, and as a result don't understand, and often fear, architecture of any kind. Others are so driven by quarterly results that a long-term, iterative initiative like enterprise SOA is out of the question. Still others insist on project-based IT funding to meet the needs of individual lines of business, a funding mechanism virtually guaranteed to slow down any initiative that seeks to reuse assets across the IT organization the way that SOA encourages.

Fortunately, you can recognize clueful CIOs because they understand the business value SOA can provide, they are willing to fund initial SOA iterations, and as the IT organization delivers value with those early projects, the CIO authorizes more of the same. Unfortunately, however, such executives are few and far between.


Enquanto a outra cara falou que "não há espaço para profissional (CIO) eminentemente técnico", saca só o trecho com negrito (meu).

Da série Flashback (ou "Graffiti - Ano III").

Esse negócio de previsões, particularmente no mundo de TI, é muito bom. Principalmente pq parece que ninguém cobra suas realizações. Então tem empresa aí que vive de "chutes". Renova-os diariamente, sem que ninguém se preocupe em validar a "pontaria".

Em outubro de 2004, no Gartner Symposium, disseram que SOA atingiria "massa crítica" em 2007. Meu comentário só teve uma palavrinha: "Exagero". Mas eu juro que não esperava ter que usar o binômio "cágado míope" para criticar a lenta adoção daquela proposta.

Na mesma época a InfoCorporate falou sobre BI e BPM. Em sua tradicional linha "jabá-quase-sem-querer" ou "engana-que-cio-gosta":

"O amadurecimento do BI e a chegada do BPM vão se tornar a mais nova aposta do mercado para conseguir justificar os investimentos em TI e fazer a tecnologia, finalmente, falar a língua dos negócios. Não é exagero dizer que o BI e o BPM devem se transformar quase em redentores dos CIO's, uma vez que prometem aumentar a performance operacional enquanto maximizam o valor dos sistemas já existentes nas empresas."

Saca só o trechinho em itálico. Ainda hoje, 3 anos depois, não consigo segurar a gargalhada. Redentores de CIO's?!? É o fim. Ou melhor, deveria ser.

Mas, como coerência e pontaria são raríssimas em nossa área, também em outubro de 2004 rolou o seguinte papo (na mesma InfoCorporate*):

1. O depto de TI como o conhecemos deixará de existir;
2. Infraestrutura de TI é commodity;
3. TI deixa de ser área de suporte aos usuários;
4. Não há mais espaço para profissional eminentemente técnico; e
5. Ou o CIO torna-se um "executivo de processos de negócios" ou segue gerenciando ativos de TI, tornando-se, assim, um ser em extinção.

1.095 dias depois, o que mudou?


* Uma coisa mudou: parei de ler a InfoCorporate...

Parece que esse é o único tipo de notícia sobre SOA (Arquitetura Orientada a Serviços) que pinta nos últimos 2 anos e tanto. Claro, além daqueles "maravilhosos" press-releases. Ah, li outro dia que quem mais sabota iniciativas SOA são os próprios departamentos de TI. Razão? Medo...

Não vejo outra origem para a longevidade dos quatro mitos citados por Joe McKendrick (a saber, se vc não foi no artigo: Web Services, Tecnologia, Custos e Registry): tudo a ver com os (cágados míopes) deptos de TI. Acho que desde o primeiro artigo publicado na face da terra sobre SOA o alerta é o mesmo: SOA é diferente de web services... Adianta? patavina nenhuma... Adianta falar que tecnologia é a peça menos relevante da proposta? necas... Só com esses 2 mitos fica fácil entender o terceiro: Custos!

Mas os deptos de TI não podem levar a culpa sozinhos. Alguns fornecedores ajudam muito na (manutenção) da confusão. Razão? Medo... e um tanto de ignorância também.

... e uma agradável e perigosa tendência.



Dion Hinchcliffe, da ZDNet, escreveu um artigo muito bom sobre mashup's em empresas. Ou, como ele sugere/pergunta, um novo "modelo para desenvolvimento de aplicações".

É muito jóia ver as massas tentando se liberar dos monolitos e planilhódromos. Mas saca só o gráfico acima: quantos usuários têm acesso aos web services, API's, códigos e widgets da própria empresa?

Alguém aí disse 1/2 dúzia? Hmm... otimista você, hem?

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.

Há uns 10 anos uns oraclepongas foram pegos com a boca na botija. Melhor dizendo, com as mãos nas lixeiras da MS. Literalmente! A história gerou um monte de piadinhas, mais direcionadas para o público 'programador': "Garbage collection?"

Faz aqui, paga aqui. A Oracle agora acusa a SAP de concorrência desleal: "roubo em larga escala"! Espionagem pura. Como? Oras, uma turma da SAP-EUA estaria fazendo o download de toda a base de conhecimentos que a Oracle tem, particularmente de duas de suas jantas recentes: PeopleSoft e J.D.Edwards. Devidamente municiada, a SAP estaria fazendo propostas indecorosas para clientes da Oracle.

Mercado saturado é isso aí: todo mundo brigando pela mesmo pedaço de pizza. Passa da hora de alguém aprender alguma coisa com o Drucker, ou então com a "Estratégia do Oceano Azul" mesmo. Tipo: esqueçam essa pizza velha e fria! Que tal uma nova torta de SOA temperada com ricos e saborosos serviços com delivery tipo SaaS?

“We’re going to do for software what Skype did for telephony”.

Assim, sem falsa modéstia, a Xcerion apresenta sua visão. Me preocupa mais o slogan: "Every computer is my computer"!! Como o Meira falou que parte da turma aí veio de Redmond, confesso que deu um frio na espinha: 'my' de quem, cara-pálida?

Só fiquei tranquilo quando vi o 'ovo de colombo' dos caras: "Free Software and OS as a service". Um sistema operacional que depende de um browser...

Ou seja, um sistema operacional de mentirinha. Quando fica alardeando que recebeu US$ 10 milhões em investimentos, comprova que não é nada tão grande assim. Nada que tire o sono de Google e MS. O Meira acha que o XIOS "detona, na boa, a tentativa do google fazer algo parecido". Céus, lembra-se quanto A Google pagou pelo YouTube? US$ 1 bilhão e quantos mesmo? tsc, tsc..

Vou ficar só no lado financeiro da coisa. Quando a poeira marketeira passar (e os caras liberarem betas), talvez eu comente a porção técnica do XIOS. Que não tem nada a ver com o SOOS proposto aqui. Nadica de nada.

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?

Mary Jo "Jo Gunne" Foley é blogueira da ZDNet: "A mulher que nunca pisca" - espiando a MS. Tadinha... ela cai em cada uma. Num post de ontem ela tentou entender/explicar a ida do Don Ferguson ('pai' do Websphere) para a MS. Confusão total: ela diz que o Websphere é igual ao .Net: mutante e indefinível (na opinião dela). Se ela desse um tempo - e algumas piscadinhas - entenderia melhor o movimento da MS.

O .Net nunca alcançou o 'break-even'. Quiçá 'massa crítica'. Grandes e médias corporações depositam suas aplicações mais críticas, particularmente aquelas que se relacionam com o mundo exterior (via web/web-services), em derivados do padrão JavaEE (Websphere, Bea WebLogic, JBoss e um monte de etc). Apesar do ímpeto com o qual surfou na onda 'web services', a MS anda um tanto perdida quando o assunto são as Arquiteturas Orientadas a Serviços (SOA). Daí a contratação do Don que, segundo a própria Jo Jo, ajudou na definição da estratégia SOA da IBM. Ele deve (tentar) fazer o mesmo na MS. Aguardem um .Net 4.0 bastante remodelado.

[Eu torceria por um produto MS-JavaEE, hehe. Seria mais fácil. E é um dos meus sonhos mais antigos...]

Para tentar entender o que o Don faria na MS, a Jo Jo correu em seu blog que ainda estava ativo no DeveloperWorks da IBM (não está mais). Surrupiou-lhe 10 tendências para os próximos 5 anos:


Não comentarei a lista. Não agora. Por enquanto só cabe o alerta de que a sigla EDA, ao lado de SOA, deve significar "Event-Driven Architecture", o termo-xodó do Gartner. Né, Jo Jo?

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

Finalmente chegamos ao ponto que mais gerou debates até agora. Como a série também está sendo publicada no Blog.MacMagazine, o debate fica persistido lá mesmo. As 5x1/2 dúzias de leitores do Graffiti detestam deixar comentários por aqui, tsc tsc. Mas vamos lá. O artigo de hoje tratará do segundo "anel" de serviços do SOOS, que estamos chamando de "Conexão". O primeiro, apresentado no artigo anterior, foi chamado aqui de "Auto-gestão".

Era uma vez um terminal. Ele só tinha um teclado e um monitor monocromático. Todo mundo chamava ele de "burro". Coitado, sem uma conexão direta com o computador central, ele não conseguia fazer nada. Nem um 2+2. Não era "burro" - era acéfalo mesmo. Aí apareceram seus primos ricos que ficaram conhecidos como PCs - computadores pessoais. Dotados de CPU e memória, nasceram autônomos. Quando começaram a ligá-los em torno de computadores centrais, praticamente decretaram a extinção dos pobres terminais. A única satisfação que restou aos "bobinhos" foi ver a longevidade de seus irmãos que, apesar de igualmente "burros", estão em todo lugar até hoje: os aparelhos de televisão. Há mais de uma década fala-se de uma geração inteligente - a TV Digital - mas a "burrice" persiste. (Parafraseando / Plagiando Nicholas Negroponte: "e olha que não estou falando da programação das TVs, ok?").

Quando falamos de *conexão*, a visão que impera até hoje é identificada por duas palavras e um sinal: "Cliente / Servidor". Nossos terminais, PCs e TVs são "clientes". Grandes computadores e emissoras de TV são "servidores". A parte minúscula e ignorada na definição, a barrinha "/", é a rede: a Conexão entre clientes e servidores. Como eu já escrevi em outro ponto desta série, tudo mudou. Mas a visão "cliente / servidor" segue aí. Qual o problema com ela e o que isso tem a ver com o SOOS?

Os papéis de "cliente" e "servidor" estão deixando de ser uma posição, um "cargo vitalício". O que determinará quando um dispositivo está servindo ou sendo servido é a transação em si. Um iPod, por exemplo, pode ser o "servidor" de músicas em uma casa ou escritório. Em outro momento ele pode ser servido por um micro, para ser devidamente "reabastecido".

Colocando de outra forma: a inteligência não estará mais centralizada. Marvin Minsky (em "The Society of Mind", de 1987), diz que "a inteligência não estará num processador central, mas no comportamento coletivo de um grande grupo de máquinas de usos mais específicos e altamente interconectadas". É por isso que a visão de um SO que funcione como um "Media Center" é de sucesso bastante duvidoso. Home theather, micro, DVD, iPod, videogame, cafeteira e nossa aguardada TV inteligente (e digital) não precisarão de um controle central. Demandarão, isso sim, uma "alta interconexão".

Como eu escrevi no artigo anterior, não é necessário que exista um único SO (um mega-monopólio) para todos os aparelhos inteligentes. O que importa é que eles compartilhem uma série de características essenciais mínimas. Creio que isso só será possível com a adoção de padrões abertos. Mas isso é outro assunto (veja nota no final do artigo).

Os padrões e protocolos de comunicação que existem atualmente já são suficientes para atender essa nova visão. A questão está mesmo em nossos SOs, em sua passividade e uma certa "burrice" (os terminais riram agora, babando veneno).


Viver em Sociedade

Quando falamos em serviços de Conexão do SOOS, queremos tratar de sua capacidade de viver em sociedade. Ele saberá identificar potenciais clientes e servidores, pares e semelhantes, amigos e inimigos. Lembrem-se que um componente (serviço) deste anel é exatamente a Segurança. O SOOS saberá evitar maus elementos e indivíduos que, desprovidos do SOOS, vivem doentes (infectados por vírus e semelhantes). Soou meio fascista mas, no mundo das máquinas, a coisa será assim mesmo. Questão de sobrevivência. Lembram-se que no artigo anterior eu falei que o SOOS "defende a sua existência"?

Novos dispositivos e novos protocolos continuarão surgindo. Quando um cara novo aparecer, como por exemplo o barman D2C (equipamento especialista em caipirinhas - dose dupla!), falando uma nova língua, ele instruirá os outros equipamentos de seu meio (micro, geladeira e afins) onde buscar o serviço que "ensina" aquela nova língua. O SOOS buscará aquele novo serviço e começará a falar instantaneamente com o querido barman: "Capitão, manda mais zuma caipira caprichada!". Ok, é quase a mesma maneira como o Neo (Matrix) aprendeu Jiu-Jitsu. Só que o SOOS não precisará de disquetes ou cartuchos, né? Ele simplesmente pega o serviço na rede. Pronto.

Tudo no SOOS estará conectado com o mundo externo. Mesmo aqueles serviços de "auto-gestão", que descrevi no capítulo anterior, dependerão da Conexão. É como se todo dispositivo possuísse um irmão gêmeo virtual, um 'avatar'. O primeiro benefício óbvio é o backup - uma cópia de segurança. Se você trocar seu micro, por exemplo, não precisará ensinar tudo de novo para ele. E o aprendizado adquirido por um dispositivo estará disponível para todos os demais. Por "aprendizado" entenda não só aquela parte de "conhecimento do dono", um serviço do primeiro anel, mas também todos os Serviços que o SOOS "aprendeu" durante sua vida em um determinado dispositivo.

Este conceito valerá tanto para funcionalidades (serviços) quanto para dados e informações. Se você comprar um editor de textos, por exemplo, ele estará disponível em seu micro mas também na sua TV. Não sei porque você utilizaria um editor de textos em uma TV, talvez para compor um email ou uma mensagem SMS (argh!) que você quer mandar para aquele apresentador 'bacana'. Você também pode adquirir uma música ou um filme. Aqui o exemplo faz mais sentido. Aquela música estará disponível para todos os seus dispositivos que saibam tocar músicas. Engraçado é que quem desenhou algumas implementações do quase-finado DRM tentava evitar exatametne isso: que você pudesse escutar sua música onde fosse mais conveniente e confortável. Não importa (mais). O fato é que você não precisará se preocupar em fazer cópias e mais cópias. Sua música (ou filme, livro, serviço) estará disponível em qualquer dispositivo. Instantaneamente.


Online X Offline

Boa parte dos debates que rolaram desde o início desta série girou em torno do duelo "online X offline". Como eu escrevi acima, o SOOS estará conectado 24x7x365 (24horas por dia, 7 dias por semana, o ano todo). Ou seja, ele será naturalmente online. Chegará o dia em que não falaremos mais tanto da tal Internet, assim como hoje não falamos da energia elétrica. Nossos filhos ou netos não darão tanta importância para ela porque ela será uma coisa natural, que "sempre esteve aí". E a ubiqüidade da rede, sua presença em tudo (do boné ao Porshe, do serviço público ao menor servicinho privado), a torna invisível. O SO do século XXI verá a Internet da mesma forma: como uma coisa natural. Lembrará sorrindo do tempo em que seus vovôs faziam conexões "dial-up".

Mas isso não significa que todos os usos que faremos de nossos dispositivos ocorrerão obrigatoriamente online. Como eu disse em uma das discussões, é uma questão de conveniência e conforto. Dados e informações serão filtrados e depositados em nossos dispositivos. Alguns serão temporários, outros com prazo de validade indeterminado (como as músicas, por exemplo). Com os serviços deve ocorrer a mesma coisa. Aquele "agente" que ajudará a fazer a declaração do imposto de renda não precisa ocupar espaço durante todo o ano. Até porque ele muda todo ano. Já os serviços de edição de textos e planilhas eletrônicas podem residir indefinidamente em nossos discos.

Acho que chegou a hora de falar um pouco mais sobre Orientação a Serviços, o OS ou SO do SOOS (sigla chique fica inalterada em inglês ou português, hehe). Como esse artigo já ficou longo pra chuchu, e já são 19hs de uma SEXta-feira, fica para a próxima.


Sobre Padrões (Sistemas) Abertos

Vou surrupiar o penúltimo parágrafo da página 47 de "A Vida Digital", único livro publicado pelo Nicholas Negroponte. Literatura obrigatória se você gosta da vida no século XXI. O livro é de 95. Vamos lá:

O conceito dos 'sistemas abertos' é vital, um conceito que exercita a porção empreendedora de nossa economia e desafia tanto os sistemas proprietários quanto os monopólios mais amplamente regulamentados. E ele está ganhando. Num sistema aberto, competimos com nossa própria imaginação, e não contra uma chave e uma fechadura. O resultado não é apenas um maior número de companhias bem-sucedidas, mas também uma gama maior de alternativas para o consumidor e um setor comercial cada vez mais ágil, capaz de rápidas mudanças e de um veloz crescimento. Um sistema aberto de verdade é de domínio público, está totalmente disponível na condição de uma fundação sobre a qual todos podem construir.

Haverá um MacSOOS, WinSOOS, SOOSix etc. Mas todos serão construídos sobre uma base totalmente aberta e livre. Dada a amplitude e relativa complexidade do SOOS, não vejo ele acontecendo de outra forma que não seja como um Sistema Aberto.

"Competimos com nossa própria imaginação". Onde ocorrerão as diferenciações? Em que campo se dará a concorrência no SOOS? Ou, colocando de outra maneira, onde estará a grana no SOOS? O próximo artigo responderá.

(ou: Como matar uma STL (sigla de 3 letras) no Berço)

A InfoCorporate ataca novamente. Saca só:

"O amadurecimento do BI e a chegada do BPM vão se tornar a mais nova aposta do mercado para conseguir justificar os investimentos em TI e fazer a tecnologia, finalmente, falar a língua dos negócios. Não é exagero dizer que o BI e o BPM devem se transformar quase em redentores dos CIO's, uma vez que prometem aumentar a performance operacional enquanto maximizam o valor dos sistemas já existentes nas empresas."

Céus! Tomara que nenhum CEO ou CFO leia a revista. Será o fim da TI. Mesmo!

Vamos lá: BPM (Business Process Management) tá aí já faz um tempinho.

Aposta do mercado para justificar investimentos em TI? Que discurso é esse? Investimento ruim não se justifica. Nunca! E cada remendo só piora a coisa. BPM depende de processos bem automatizados. Não há milagre!!

Redentores dos CIO's?!?! Quem vender (comprar) BPM assim tá gastando a última bala. Pára com isso! Em média, 50% dos projetos de ERP falharam. 60% dos projetos de CRM zicaram. E 75% dos projetos de BI melaram. Pq? Pq foram apresentados como panacéia. Como o grande milagre. Agora cada nova onda tem que ser o novo grande milagre. Já cansou, né? Repare nos percentuais. Cada nova "moda" depende da anterior. É uma nova fatia no 'stack' da infra-estrutura de aplicações corporativas. Se a fatia de baixo tá "meia-boca", como a de cima pode melhorar a nota do conjunto da obra? Impossível! Então a taxa de fracassos só faz aumentar. Matemática pura!!

Apesar da aberração e do nosso histórico, o IDC espera que gastemos US$1bi com BPM. Pode? Pode... infelizmente.