1

2

Apresentação

Me senti muito honrado por ter recebido do Cezar Taurion o convite para escrever a apresentação de seu livro sobre Arquitetura Orientada a Serviços (SOA), organizado a partir de uma compilação de informações postadas em seu Blog e que veio a ser publicado e distribuído gratuitamente em meio exclusivamente eletrônico através da Internet (eBook).

Antes de começar a escrever me dei conta de que todos esses assuntos (SOA, Blogs, eBooks) tão comuns hoje em dia, eram praticamente desconhecidos há quatro ou cinco anos. Isso nos dá uma noção do ritmo acelerado da evolução tecnológica, algo impressionante e ao mesmo tempo assustador, porque tais novidades, que parecem chegar em forma de ondas, sempre trazem a reboque um novo conjunto de informações que tentamos compreender, assimilar e aplicar, até sermos encobertos por uma outra onda. SOA se apresenta exatamente como uma dessas ondas.

A adoção de SOA muitas vezes gera uma expectativa de que seus alegados benefícios serão alcançados simplesmente pelo sucesso de sua implantação. Entretanto os resultados mais significativos e estratégicos de uma transição para o mundo SOA, como por exemplo o aumento da agilidade nos negócios, só podem ser realmente alcançados (em seu potencial máximo) através de uma abordagem consistente desde o início, ainda na fase de design da lógica de automação do negócio aliada a uma flexibilidade para suportar mudanças.

As mudanças, como bem sabemos, são constantes no mundo dos negócios. Crises, fusões, aquisições, regulamentações de mercado, globalização, terceirização, etc. No longo prazo, quase todos os aspectos de um negócio são suscetíveis a mudanças que, por sua vez, geram novas demandas para o ambiente tecnológico de suporte. As metodologias de desenvolvimento de sistemas mais pragmáticas (e modernas) acreditam no processo incremental, no qual a mudança é um aspecto inevitável e pode ocorrer em qualquer estágio, ou seja, os sistemas estão em constante evolução e a separação entre o desenvolvimento e a manutenção de um sistema tornou-se cada vez menos significante. Por essa razão a capacidade de lidar com mudanças significativas no design e no comportamento de um sistema é algo crítico ao longo do seu ciclo de vida. Esse é o principal diferenciador da engenharia de software das outras engenharias e, não por acaso, é um dos grandes apelos do desenvolvimento de software orientado a serviços.

Na verdade, diversos paradigmas para arquitetura e desenvolvimento sistemas surgiram para tentar endereçar as constantes e cada vez mais elaboradas necessidades de mudanças. Ao longo dos últimos cinquenta anos passamos por sistemas monolíticos, estruturados, cliente/servidor, dispostos em três camadas, baseados em objetos e componentes distribuídos até finalmente chegarmos aos sistemas baseados em serviços (até a próxima onda, é claro...). O fato é que a cada novo paradigma, surgem discussões acaloradas acerca de sua viabilidade, longevidade e coexistência com o paradgima anterior. Com SOA não é diferente. Existem muitas opiniões sobre o que constitui a orientação a

3

serviços, como e quando adotá-la, originárias dos diversos fornecedores de tecnologia, empresas de consultoria e do mundo acadêmico. Esse livro trará, na forma de compilações de posts de um Blog, o registro de algumas reflexões sobre SOA, suas aplicações, implicações, limitações e potenciais, a partir da visão do autor, cuja experiência de mercado traz dimensões interessantes a essa discussão. Vale a pena conferí-las.

Marcelo Sávio Arquiteto de TI da IBM Brasil http://www.linkedin.com/in/msavio http://msavio.myplaxo.com/

4

Introdução A idéia de publicar um livro com a coletânea de posts que já escrevi para o meu blog no developerWorks (www.ibm.com/developerworks/blogs/page/ctaurion) vinha me martelando há algum tempo. As minhas observações sobre os acesso ao blog mostravam que depois de algum tempo os posts eram “esquecidos”, uma vez que o ritmo de inserção de novos posts tem sido intenso. Gosto de escrever e um blog me dá a liberdade que as colunas nas revistas especializadas (escrevo para Computerworld Brasil, Mundo Java e Linux Magazine), por razões editoriais, não permitem. De maneira geral levanto um post a cada três ou quatro dias. Como escrevo os posts de acordo com o momento, muitas vezes o texto pode até parecer meio deslocado para quem não esteja acompanhando sistemáticamente o tema. O volume de material acumulado, acredito, é bem razoável. O blog começou em janeiro de 2007 e em julho de 2009, quando da preparação deste livro, já somava mais de 400 posts. Surgiu a idéia: por que não agrupar os posts por temas e publicá-los para acesso online? Uma conversa com meu amigo desenvolvedor e escritor, Claudio de Souza Soares, definiu o projeto. Sim, vou publicar os posts em forma de livro eletrônico. A primeira etapa foi agrupar os posts por assuntos, identificando as relevâncias entre eles. As tags me ajudaram nisso. Assim, cada assunto ou conjunto de assuntos se tornará um livro. Procurei manter os posts, na medida do possivel iguais aos publicados originalmente. Claro que corrigi alguns erros ortográficos, que passaram em branco quando os posts foram inicialmente levantados... Este livro, o quinto da série, aborda um tema que me despertou muita atenção: SOA ou Services Oriented Architecture. SOA teve seu período de maior procura de 2006 a 2008 (vejam gráfico abaixo, obtido do Google Trends), começando após a ceder lentamente seu espaço na mídia para outros temas como Cloud Computing. Lembro que naquele período chegava a fazer palestras sobre SOA ao ritmo de uma por semana.

5

Não que hoje SOA tenha ficado menos importante, mas à medida que um assunto sai da mídia, é que sua disseminação já começa a ser fato. Deixa então de ser notícia. SOA já vem sendo adotado de forma crescente e seus conceitos já estão razoavelmente absorvidos. SOA hoje é mainstream. Seus conceitos já estão embutidos nos aplicativos escritos pelas empresas usuárias, nos ERPs e nos middlewares dos principais fornecedores, como o WebSphere da IBM. SOA, segundo o Gartner já está entrando no ciclo do “Plateau of Productivity”, onde deixa de ser hype e sua utilização torna-se mais ampla. Os usuários já relatam casos de sucesso em número crescente e apontam que a proposição de valor de SOA inclui maior agilidade da organização em alterar seus sistemas frente às inevitáveis mudanças no cenário de negócios, e pela maior valorização dos ativos de software (sim, software também pode e deve ser medido com base em Return on Asset), obtido pelo maior reuso do código. SOA também demandou a criação de novos skills profissionais, o que abriu oportunidades para inúmeros cursos e livros especializados. A literatura disponível é imensa: uma pesquisa na Amazon nos retorna milhares de livros que incluem SOA em seus títulos. Além disso, SOA também é indutor de novos modelos computacionais como Cloud Computing e Software-as-a-service (SaaS). Por outro lado, muitos fornecedores de software se dizem aderentes à SOA, embora nem sempre o sejam. Uma maneira simples e rápida de checar sua afirmação é validar se seu software é SOA é avaliar seu nível de componentização. Se o delivery de novas funcionalidades for feita por componentes, sem afetar o sistema em operação é verdadeiramente SOA. Mas se ainda for necessário todo um ciclo de upgrade que demanda uma completa instalação da nova versão, nos moldes tradicionais dos softwares monolíticos, SOA, neste fornecedor, ainda estará restrito ao discurso. O objetivo deste ebook não é ensinar SOA, pois uma coleção de posts não ensina nada a ninguém. Mas, estes posts revivem os questionamentos e dúvidas que este conceito, então novidade, trazia e serve para compararmos o que falávamos há meros dois ou três anos com os dias de hoje. Muita coisa mudou, principalmente com relação à absorção dos conceitos, embora muitas empresas ainda estejam nas fases iniciais de sua adoção. Portanto, estes posts nos resgatam algumas destas discussões sobre o assunto. Todos os URL que aparecem nos textos foram acessados e checados durante a preparação original dos posts, mas como a Web é extremamente dinâmica, existe a grande possibilidade de alguns destes URL já não existirem ou terem sido alterados, pelos quais pedimos antecipadamente nossas desculpas.

6

E, finalmente, lembro que as opiniões expressas nesta série de livros (como o foram no blog) são fruto de estudos, análises e experiêncis pessoais, não devendo em absoluto serem considerdas como opiniões, visões e idéias de meu empregador, a IBM, nem de seus funcionários. Em nenhum momento, no blog e aqui, falo em nome da IBM, mas apenas e exclusivamente em meu nome. Cezar Taurion Setembro de 2009

7

Conhecendo SOA SOA significa Services Oriented Architecture ou Arquitetura Orientada a Serviços e, portanto, antes de mais nada precisamos definir o que é arquitetura. Arquitetura é o processo de projetar construções como edifícios e casas. Se o arquiteto desenha uma casa, o objetivo dela será servir de residência. Se ele projeta um edifício de escritórios, seu objetivo será prover espaço para atividades profissionais. Cada desenho tem suas peculiaridades, de acordo com os objetivos e características próprias da construção. Claro que embora cada prédio ou casa seja diferente em seu desenho e arranjo fisico, utilizam materiais comuns a todos e obedecem a regulamentos, padrões e leis, inclusive físicas. Por exemplo, não se pode construir um prédio de muitos andares sem uma boa fundação (lei da gravidade). Ou então, por alguma imposição legal, não se pode construir prédios de mais de quatro andares na beira de determinada praia. Quando falamos em arquitetura de TI estamos falando do desenho de uma infraestrutura tecnológica que suporte as demandas de um determinado negócio. Cada negócio ou empresa tem suas carateristicas próprias e assim cada uma deve ter sua própria arquitetura. Embora cada empresa desenhe sua própria arquitetura, deve utilizar tecnologias e padrões comuns. Entretanto, uma arquitetura tecnológica, embora não seja tão proibitiva quanto à tradicional (não se pode transformar um andar de 200 metros quadrados em outro de 400 metros quadrados) ou restritiva quanto a mudanças (imagine transformar um prédio projetado e construído para ser comercial em residencial...quantas paredes terão que ser derrubadas!), nem sempre é flexível o suficiente para acomodar a volatilidade do negócio. Um exemplo comum: sua empresa adquiriu outra, que dispõe de uma infraestrutura tecnológica totalmente diversa. Não será uma tarefa fácil integrar todos estes “novos” sistemas aos que já estão em operação. O que SOA propõe é uma mudança nos paradigmas das arquiteturas de TI atuais. Hoje as arquiteturas são basicamente constituídas de aplicações construídas em cima de padrões proprietários, com quase proibitivas restrições de interoperabilidade. Uma aplicação escrita em VisualBasic não consegue utilizar um objeto escrito em Java. O acesso a determinado ERP só pode ser efetuado através das rotinas de acesso específicas e proprietárias deste ERP. Um aplicativo escrito para operar em Windows não pode ser transferido automáticamente para uma máquina que roda Linux... Por outro lado, as mudanças constantes no cenário empresarial requerem um grau de flexibilidade no modelo de negócio que não é suportada pela atual infra-estrutura de aplicações de TI. Quaisquer mudanças nos processos ou no ambiente de negócios impactam as aplicações existentes. Pela dificuldade de adaptá-las ou reorganizá-las, vemos que as aplicações acabam sendo um empecilho no caminho das mudanças ou movimentos estratégicos das corporações.

8

A proposta do SOA pode ser mais facilmente visualizada quando o associamos ao tradicional brinquedo Lego, onde com as mesmas peças podemos criar rapidamente objetos distintos, simplesmente combinando os objetos de maneira diferente. Como funciona na prática este conceito? Imaginemos que você é o CIO de uma empresa que interopera comercialmente com diversas outras. Você precisa substituir uma aplicação crítica, trocando a sua tecnologia. Com certeza isto vai gerar muito trabalho de modificação nos interfaces desta aplicação com as demais, na sua empresa e nas empresas parceiras. Agora, visualizemos um cenário (cada vez mais comum) onde dezenas ou mesmo centenas de empresas interoperam entre si, com constantes evoluções e trocas de tecnologias. Dá para imaginar o pesadelo? Adotar SOA, eliminando os interfaces proprietários, torna as modificações muito mais simples e rápidas. Se as aplicações não falam mais diretamente umas com as outras, mas interoperam trocando mensagens SOAP através de Web services, qualquer substituição de alguma aplicação não afeta o cenário como um todo. As demais aplicações nem precisam saber desta substituição. SOA, portanto, é um passo enorme na direção de um mundo cada vez mais interconectado!

9

Usando SOA SOA (Services Oriented Architecture) é um tema cada vez mais quente. Recentemente o IDC divulgou um relatório chamado “Top 10 Predictions – IDC Latin America Predictions 2007” onde SOA foi citado como saindo da esfera da teoria e dos debates para o mundo real (“SOA goes from idea to reality in 2007”). Segundo o IDC, SOA está na lista de prioridades dos CIOs em todo o mundo. Como aceleradores para 2007, o IDC destaca que à medida que os modelos de licenciamento caminham na direção de Software como Serviço, mais ênfase será dada ao SOA, principalmente pela sua potencialidade de adicionar funcionalidades mais rapidamente. Também cita a Nota Fiscal Eletrônica em implementação no Brasil como um impulsionador de SOA, bem como lembra que à medida que caminhemos para consolidação de servidores e data centers, SOA vai se tornar mais e mais importante quando passarmos a olhar a consolidação também na camada das aplicações. Por último o IDC cita a consolidação que já ocorre e deverá continuar ocorrendo entre empresas de aplicativos, que precisam implementar os conceitos SOA para garantir a interoperabilidade entre seus pacotes. Outras recentes pesquisas corroboram este crescente interesse por SOA. Por exemplo um relatório do Aberdeen Group (“What CIOs Should Know About SOA”) mostrou que os 3 principais drivers para adoção de SOA são o desenvolvimento de novas funcionalidades, o reuso de aplicações via Web services e o melhor gerenciamento da complexidade do portfólio das aplicações de TI. Pesquisa da AMR Research (“Services Oriented Architecture: Survey Findings on Deployment Plans for the Future”) mostrou que 21% empresas já estão usando SOA e 53% outras planejam adotar SOA nos próximos 24 meses. E das que estão usando SOA, 60% pretendem aumentar seus investimentos SOA! Sinal claro que estão conseguindo bons resultados. O Gartner Group recentemente disse que “80% of customers will be using SOA for new product development in 2008”. E o Forrester Research em uma pesquisa feita no fim de 2005 (“Forrester’s Business Technographics November 2005 North American and European Enterprise Software and Services Survey”), com mais de 600 empresas americanas e européias descobriu que 53% estariam usando SOA no fim do ano passado. E que 39% já estavam usando. Confirmando o grau de satisfação de quem usa SOA, 69% das empresas que já adotaram este modelo disseram que vão aumentar seus invstimentos SOA. A pesquisa foi mais além e descobriu também que 83% das empresas que adotam SOA o usam para resolver problemas de integrações internas, mas que uma parcela significativa (46% das grandes corporações e 27% das médias) estão usando SOA para transformar seus negócios!

10

Esta é um mudança significativa quando comparamos SOA com o modelo de Orientação por Objeto (OO), quando dificilmente conseguiu-se correlacionar implementações com iniciativas de transformações de negócio. As implementações OO foram focadas no campo técnico.

11

Dando os primeiros passos em SOA SOA é uma evolução significativa no desafio de se resolver um dos principais problemas da tecnologia: a habilidade de se conectar e interoperar sistemas sem depender de softwares e interfaces proprietários. Sua proposta é simples: conectar sistemas através de interfaces abertos baseados no padrão XML (Extensible Markup Language). Em um mundo cada vez mais “plano”, a visão de processos verticalizados, em silos, limitados à departamentos estanques, está sendo substituída por uma visão de processos mais holística, horizontalizada e integrada. Estes processos, por sua vez não mais acabam nos muros da empresa, mas extrapolam seus limites físicos, criando “empresas virtuais”, com atividades integradas sendo efetuadas por diversas outras empresas parceiras. Interagir e interoperar processos entre empresas demanda interoperabilidade entre as aplicações. Infelizmente a interoperabilidade vem sendo conseguida a duras penas, através de tecnologias e interfaces proprietários, com custos altíssimos e demoras muitas vezes intoleráveis para as nossas necessidades de flexibilidade e rápida reação às mudanças do mercado. Interfaces abertos e padronizados não são novidade no mundo da informática. O correio eletrônico e a WWW (World Wide Web) são bons exemplos. Podemos enviar mensagens para qualquer computador, sem precisar perguntar qual o sistema operacional ou software de correio que a outra pessoa está usando. Você está lendo este post que escrevi e disponibilizei no blog sem me preocupar em saber qual o computador que você vai usar, qual o seu sistema operacional e qual o seu browser. Isto tudo acontece porque os interfaces necessários são padronizados e abertos. Por que não adotar padrões abertos na interoperabilidade entre aplicações? A idéia é óbvia, mas implementar e adotar padrões abertos não é uma tarefa fácil. Existem barreiras tecnológicas e comerciais. Muitos vendedores desenvolvem suas tecnologias e tentam impor esta tecnologia proprietária como um padrão de fato ao mercado, forçando sua adoção pelos outros atores da indústria. Para um padrão aberto se consolidar, a indústria como um todo (fornecedores e usuários) deve participar de seu desenvolvimento e incentivar sua adoção. Os padrões WWW são exemplo desta cooperação. O consórcio W3C (WWW Consortium – www.w3.org ) é responsável pela evolução das especificações do padrão HTML (Hypertext Markup Language), que permite a qualquer browser acessar e visualizar documentos, como este que vocês estão lendo. Mas, voltando à nossa busca pela interoperabilidade, alguns passos importantes foram dados nas últimas décadas, que contribuíram em muito para chegarmos ao SOA. Um deles foi o advento do conceito de orientação a objetos. Infelizmente, embora o conceito fosse muito interessante, não se conseguiu na prática, obter a desejada interoperabilidade entre os objetos de diferentes tecnologias. Uma biblioteca de objetos escritos em VisualBasic não interage com uma biblioteca de objetos escritos em Java e vice versa. E

12

isto apesar dos esforços de organizações voltadas a especificar padrões, como o OMG (Object Management Group) que desenvolveu a especificação CORBA (Common Object Request Broker). Na teoria, CORBA foi uma grande idéia, mas devido a concorrência comercial acabou não decolando. A Microsoft por exemplo, criou seu próprio “CORBA”, denominado de DCOM (Distributed Component Object Model), que facilita o processo de uso de objetos dentro do mundo Microsoft. Entretanto, não é possível usar este padrão fora das plataformas Microsoft. Mas as idéias da orientação a objeto ficaram. Porque não identificar as causas de não ter tido sucesso? Obviamente a falta de padrões abertos era a principal. Com o advento do padrão XML, que hoje já é uma convenção global, aceita por qualquer empresa ou usuário da informática, podemos pensar em uma nova solução para o desafio da interoperabilidade. Assim, surgiu o conceito de softwares denominados Web Services, usando os padrões abertos da Internet como meio de comunicação e o padrão XML como formato para troca de mensagens. Os padrões Web Services foram sacramentados pelo W3C através da especificação de padrões de interoperabilidade, todos baseados em XML, que são o SOAP (Simple Object Access Protocol) para troca de mensagens entre aplicações, UDDI (Universal Description Discovery and Integration) como padrão para localização e identificação de Web Services, e WSDL (Web Services Description Language) para descrição dos Web Services e suas funcionalidades. Com Web Services podemos realmente pensar em interoperabilidade. Mas chamo atenção para um ponto importante: Web services por si não significa SOA. Uma pesquisa do Forrester (“Forrester’s Business Technographics November 2005 North American and European Enterprise Software and Services Survey”) me apóia nesta chamada: ela mostrou que 67% das empresas pesquisadas usavam Web services, mas apenas 39% se consideraram usando SOA. Das empresas que disseram já ter adotado Web services, menos da metade, 47%, também adotaram SOA. Bem, e SOA? SOA é fundamentalmente baseado em Web Services e padrões abertos! A mesma pesquisa mostrou que das empresas que adotaram SOA, 80% usavam Web services. Para saber mais sobre SOA recomendo visitar www.ibm.com/soa e www.ibm.com/developerworks/soa . Também sugiro dar uma olhada no Wikipedia (http://en.wikipedia.org/wiki/Service-oriented_architecture) . Vocês vão descobrir muita coisa interessante!

13

Ainda existirão aplicações no mundo SOA? Uma dúvida que surge nos vários debates em que participo: como SOA são componentes que são aglutinados e coreografados para compor uma aplicação, terá ainda sentido falar em pacotes como ERP, CRM ou Recursos Humanos? Na minha opinião, o conceito de aplicação monolítica, onde os seus limites são claramente especificados (todo mundo sabe onde começam e terminam sistemas como RH e contabilidade) deixa de existir no mundo SOA. É substituído pelo conceito de aplicações compostas de processos e respectivos componentes, coreografados para agirem como se fosse uma “aplicação virtual”. Os componentes que constituirão estas futuras “aplicações SOA” podem ser divididas em duas camadas, uma voltada para interação com os usuários e outra para suportar serviços de negócios. A camada de serviços de negócio é constituída de componentes que implementam os processos de negócio. Mas na prática como construiremos estas futuras aplicações compostas? Se mudarmos a definição e o conceito das aplicações tradicionais, com certeza teremos que repensar os processos de desenvolvimento, a organização das equipes de desenvolvimento e mesmo os skills necessários. Teremos também de repensar questões de como alocar o budget, uma vez que uma área de negócios poderá utilizar componentes já desenvolvidos por outras áreas. Como pagar pelo uso deste componente? Talvez em algum dia no futuro, uma parcela significativa do processo de desenvolvimento poderá ser apenas uma reaglutinação de componentes já existentes. Uma nova aplicação poderá ser inteiramente construída simplesmente rearranjando componentes já prontos. Teremos uma situação curiosa, pois ficará difícil separar a atividade de desenvolvimento da manutenção. Portanto, ao iniciar nossa jornada em direção ao mundo SOA, começamos a listar alguns questionamentos que teremos pela frente. Que impactos o SOA acarretará na organização de TI? Como alocar prazos e budgets para projetos onde muitas vezes teremos apenas que descobrir e aglutinar componentes que já estão prontos? Qual o perfil do profissional que fará a coreografia dos componentes? Enfim, teremos belos e desafiadores dias pela frente!

14

SOA e a modernização das aplicações legadas Todos as empresas tem centenas de aplicações legadas em seu portifólio. E estas não são apenas as aplicações Cobol escritas há dez ou quinze anos atrás, mas também os programas escritos em Perl ou VB há três ou cinco anos, cujos autores já não estão mais na empresa ou simplesmente mudaram de função. Importante lembrar que nomear uma aplicação como legada não signfica vê-la de forma pejorativa, uma vez que estas aplicações geralmente operam o cerne dos negócios das empresas. Por exemplo, mais de 80% de todas as transações eletrônicas globais são processadas pro mainframes. Um problema que é comum na imensa maioria das empresas é que estas aplicações foram escritas sob o paradigma do modelo computacional da época, como, por exemplo cliente-servidor. São aplicações monolíticas e nem sempre fáceis de serem modificadas. Além disso, muitas vezes as tecnologias usadas para escrevê-las não eram as mais adequadas. É comum ver aplicações escritas em VisualBasic (VB) ou PowerBuilder (PB) simplesmente porque a empresa definiu em determinada época que o VB ou o PB seria a tecnologia para todas as aplicações. É o clássico exemplo que os americanos chamam de “one size fits all”, onde uma única ferramenta é usada, a despeito de ser ou não a melhor solução para cada caso. Nos últimos anos também vimos a adição de funcionalidades de Web adicionadas às aplicações já existentes, incorporando novas tecnologias e novas demandas de interação com os sistemas legados. Estamos diante de um imenso desafio. As empresas precisam ser mais ágeis e flexíveis, mas as aplicações que as sustentaram até hoje não respondem com a velocidade adequada. Gasta-se muito tempo e dinheiro nos esforços de integração e manutenção, sobrando muito pouco para projetos novos e inovadores. Por outro lado, sabemos que as aplicações legadas devem continuar conosco durante muito tempo. De maneira geral as aplicações ficam muito mais tempo ativas que o inicialmente planejado. Uma solução seria desenvolver novamente estas aplicações. Mas algumas estatísticas como a da Software Productivity Research mostram que pode custar pelo menos 5 vezes mais desenvolver um novo código que reutilizar o código já existente. Considerando que pelo menos de 40% a 60% do código existente nas empresas pode ser reusável, por que não explorar um novo paradigma computacional, o modelo SOA, como solução para modernização do portifólio de aplicações? Relembrando, SOA é uma arquitetura para construção de sistemas distribuídos que visualizam a funcionalidade das aplicações como serviços. A adoção do modelo SOA, vista por uma ótica pragmática, permite modernizar as aplicações, reusando o código já existente. Permite transformar ativos legados em componentes visualizados como serviços. Importante considerar que adoção de SOA tem um componente tecnológico muito forte, mas transcende a tecnologia, envolvendo mudanças na organização e no “pensamento” dos desenvolvedores.

15

Entendendo como e onde SOA e Web Services interagem Tenho observado que muitas vezes as discussões sobre SOA caminham para um viés totalmente tecnológico. Mas, SOA é mais que tecnologia pura. SOA é uma arquitetura de software. E, claro, tem um componente tecnológico forte, que são os módulos de software que implementam os conceitos especificados pela arquitetura. Estes componentes podem ser os Web Services. Assim, SOA deve ser visto como princípios de desenho de software enquanto que os Web Services tratam das especificações tecnológicas. E o que são Web Services? Podemos chamar de Web Services qualquer software que utlize os padrões abertos WSDL (Web Services Descrition Language), SOAP (Simple Object Acesses Protocol) e UDDI (Universal Descrirption, Discovery and Integration). Para implementar a arquitetura SOA não precisamos de Web Services, mas para garantir plena interoperabilidade são necessários padrões abertos. Daí a confusão entre os termos SOA e Web Services, quando muitas vezes SOA é visto como simples implementações de Web Services. O interesse pelo SOA é crescente. A substituição do paradigma cliente-servidor e desenho monolítico por uma arquitetura mais flexível é uma necessidade de negócios. O atual cenário de negócios demanda respostas rápidas às frequentes mudanças no cenário empresarial. Vamos imaginar o mercado financeiro, que precisa ser muito rápido em lançamento de produtos e reações a movimentos da concorrência. Um banco, ao identificar o potencial de negócios de um novo produto, tem uma janela de oportunidades bem pequena para colocá-lo no mercado, divulgá-lo e ganhar dinheiro com ele, antes que a concorrência anuncie também com produtos similares. Este produto é implementado por processos de negócio e como todo produto financeiro, deve ser plenamente suportado por tecnologia da informação e aplicações. Se o banco puder aproveitar partes dos processos (componentização dos processos de negócios) e dos aplicativos já existentes, sem contorcionismos em modificar códigos de programas espalhados por dezenas de aplicações, com certeza teria uma vantagem competitiva significativa. O modelo SOA propõe exatamente isso: embutir componentes de software já existentes na nova aplicação que vai suportar o novo produto. Claramente vemos que os benefícios com SOA passam por por uma reposta mais rápida ao mercado (menor time-to-market) e manutenções mais rápidas e menos custosas. Implementar SOA tem uma abrangência maior que uma simples implementação de tecnologia. Envolve mudanças no modelo de desenvolvimento e princípios de desenho de software. Levar o debate SOA apenas para o lado tecnológico não trará os benefícios esperados.

16

SOA também é tecnologia! Nos últimos posts sobre SOA enfatizei o fato de precisarmos olhar além da tecnologia. Mas agora gostaria de voltar a trocar idéias sobre tecnologia. Falar em tecnologia no mundo SOA é algo mais que colocar uma camada de Web Services em cima das aplicações atuais ou novas. Devemos olhar o fator tecnologia sob um ângulo estratégico, definindo uma plataforma SOA que seja adequada aos objetivos da empresa. Afinal se nossa entrada no mundo SOA é para conseguirmos que a organização se torne mais ágil e rápida às mudanças no cenário empresarial, fazendo com que as integrações entre suas próprias aplicações e do ecossistema em volta seja mais fácil, não podemos olhar a plataforma tecnológica unicamente pelo simplista viés do “mais barato...”. A plataforma SOA que você adotar (plataforma é a infra-estrutura de software que você vai usar para construir, entregar, monitorar e gerenciar serviços) vai influenciar sua capacidade de alcançar ou não os objetivos a que você se propôs ao entrar no SOA. Portanto, é um aspecto que deve ser analisado com bastante critério. SOA não é um produto único que se compra na prateleira (“quero um software SOA...”), mas um conjunto de produtos de software que você vai aos poucos adicionando e integrando ao seu portifólio, de acordo com o grau de maturidade de SOA na empresa. Assim, escolher a plataforma SOA é uma variável de grande importância para a concretização de sua estratégia. Na minha opinião, o alcance dos seus objetivos com SOA vai estar de acordo com a sua visão e investimentos em SOA. Se ela for restrita, os benefícios alcançáveis também serão poucos.

17

Discutindo SOA e comendo pão de queijo em Belo Horizonte Nesta próxima terça estarei em Belo Horizonte, participando de um Road Show da IBM. Minha palestra será sobre SOA e será uma boa ocasião para trocar algumas idéias sobre o tema com nossos clientes e prospects. Aliás, também será uma excelente ocasião para uma boa cozinha mineira, fechando a tarde com pão de queijo! Voces sabiam que o Wikipedia já tem uma entrada para pão de queijo? Bem, deixando de lado a gula, e voltando ao SOA, na minha opinião, a orientação a serviços é uma disrupção no modelo de sistemas. Embora na maioria das vezes as discussões e atenções dos profissionais de TI estejam focadas nos aspectos tecnológicos, SOA envolve também mudanças conceituais nos processos e na organização de TI. A organização de TI vem mudando ao longo dos tempos. Na era dos mainframes era basicamente centralizada. No paradigma cliente-servidor vimos uma tendência à descentralização. A era do SOA vai demandar uma nova organização... SOA permite criar um modelo digital dos serviços (unidades de trabalho) da organização e para isto acontecer é necessário que haja uma profunda interação entre TI e o negócio em si. O modelo de orientação a serviços incentiva que tanto TI como negócios falem a mesma linguagem, pois ambos devem acordar sobre os serviços, suas funcionalidades e níveis de granularidade. Sem uma mesma linguagem jamais estes serviços poderão ser implementados adequadamente. Portanto, concentrar o foco na tecnologia não será suficiente para que a organização chegar ao modelo orientado a serviços. Na minha opinião, o sucesso na empreitada de SOA vai além da tecnologia. A área de TI deverá rever seus processos de desenvolvimento e manutenção bem como o skill dos seus desenvolvedores e arquitetos, que tem que ser ajustados a um novo e mais intenso modelo de relacionamento TI-negócios. Neste contexto surge a figura de um projetista SOA, que deve ter uma profunda compreensão das características dos processos de negócio e ser o elemento de ligação entre a visão de TI e de negócios. O projetista SOA é o indivíduo que vai traduzir os processos de negócio em especificações de serviços, para posterior implementação em códigos de software.

18

Puxa, mais SOA! As aplicações no tradicional e conhecido mundo de TI tem claramente definidas as responsabilidades de TI e das áreas de negócios. O funding para uma determinada aplicação a ser desenvolvida vem da área de negócios que a usará e cabe a TI desenvolvê-la, em colaboração com estes usuários. Mas no mundo SOA falamos em incentivo ao reuso de serviços (ou componentes) e em aplicações compostas, que são aplicações desenvolvidas reusando-se em grande parte serviços já existentes. Aí as coisas mudam. De quem é a propriedade do serviço que poderá ser reusado por diversas aplicações? Quem vai alocar o budget para seu desenvolvimento? Quem dará a palavra final em questões como prioridade no seu desenvolvimento ou eventual modificação? Estes serviços reusáveis serão compartilhados por várias aplicações e pode-se questionar: que unidade de negócios vai bancar os custos de desenvolvimento e como recuperar estes custos quando outras áreas da empresa utilizarem este serviço? Os mecanismos atuais de alocação de recursos não prevêem compartilhamento. A aplicação pertence a uma unidade de negócios e ela que decide sobre seu futuro. Na minha opinião estamos criando com SOA um novo e diferente ativo de TI: serviços compartilháveis. Estes serviços não pertencem a uma área da empresa, mas à toda a empresa. Precisamos, portanto, de um novo modelo de governança. Neste modelo deve-se avaliar se o serviço será reusável e caso seja, seu desenvolvimento e posterior manutenção não poderá onerar o budget de uma área específica. Os processos de change management também deverão ser revistos para contemplar a questão do compartilhamento. Acredito que SOA vai resultar em grandes benefícios para as organizações. Mas a cada dia fica mais claro que precisamos pensar SOA indo além da tecnologia, revendo também os processos, skills e a organização de TI.

19

SOA nos traz de novo a computação centralizada? O último post sobre SOA gerou um comentário muito interessante, com uma indagação: “SOA traz de volta a computação centralizada (física e logicamente) em termos de hardware e software?” . Na minha opinião SOA é computação distribuída por excelência, pois permite expor e acessar serviços onde que eles estejam. E um cenário futurista de “Services Network”, inclusive com serviços prestados por empresas especializadas, pode se tornar presente muito rapidamente. SOA tem muita sinergia com o conceito de Grid Computing. O cenário empresarial dos próximos anos aponta para um contexto de organizações virtuais onde SOA e Grid se encaixam perfeitamente. Abaixo vou reproduzir um capítulo do meu livro sobre Grid Computing (Grid Computing: um novo Paradigma Computacional), editado pela Brasport: “Estamos hoje entrando céleres em uma nova era, a sociedade da informação e do conhecimento. Os paradigmas e valores são diferentes das eras passadas. Na era da agricultura conhecemos a hierarquia. Na era industrial vimos o nascimento da burocracia e agora, na era do conhecimento, vivenciamos as redes organizacionais empresariais. Uma rede é um tipo de organização dinâmico e cooperativo criada com a finalidade de explorar oportunidades de mercado. A rede pode ser interna a uma empresa, com a criação de times ou entre empresas. Uma rede é baseada em competências especializadas, onde cada membro da equipe, pessoa física ou empresa, contribui com seus conhecimentos específicos para a melhoria do todo. Neste cenário, as empresas começam a se estruturar em organizações virtuais, com composições diferentes a cada projeto ou iniciativa de negócio. A transformação das empresas em organizações virtuais passa por três aspectos de mudança culturais fundamentais: a cultura da confiança, a cultura da competência e a cultura da tecnologia da informação. Confiança porque uma organização virtual incentiva à colaboração e cooperação entre seus membros. Para isso é fundamental que os objetivos comuns sobreponham-se a objetivos individuais. A competência trata tanto as questões relacionadas com os recursos materiais (máquinas e equipamentos) como imateriais (conhecimento e procedimentos). A tecnologia da informação é primordial para que as empresas relacionem-se de maneira ampla, rápida e segura. Esta transformação do cenário de negócios não é opcional. É um fenômeno inevitável. As empresas convencionais precisam mudar para sobreviver, pois não terão a eficácia para se manterem competitivas, atuando isoladamente. As tecnologias da informação por trás destas mudanças trazem demandas de capacidades computacionais elevadas. Estamos falando de manufatura virtual, engenharia virtual e realidade virtual. A engenharia virtual, por exemplo, não se utiliza mais apenas do papel

20

e das pranchetas dos desenhistas. Com o surgimento da engenharia concorrente ou simultânea e com os avanços da computação, desenvolvem-se os projetos de engenharia por várias equipes, dispersas geograficamente. A engenharia virtual pressupõe que diversos engenheiros, localizados até mesmo em países diferentes, estarão trabalhando simultaneamente no mesmo projeto. Com a utilização dos conceitos de simulação e realidade virtual, os projetistas conseguem visualizar a realidade, facilitando o desenvolvimento do projeto e a correção de erros. O empreendimento da construção de um objeto complexo como uma aeronave ou um automóvel demanda milhares de pessoas e centenas de empresa envolvidas em todas as etapas do seu ciclo de vida, da concepção e projeto até fabricação e suporte pós-venda. Em cada etapa um conjunto de competências especificas é necessário. A organização virtual propõe o compartilhamento de recursos (como a demanda de mercado torna-se a cada dia mais dinâmica, as empresas devem usar em comum seus recursos) e compartilhamento de conhecimento (nenhuma empresa pode fazer tudo, todo o tempo. Torna-se cada vez mais difícil uma empresa manter isoladamente todo o conhecimento necessário para fabricar e vender produtos e serviços em mercados cada vez mais globalizados e exigentes), que tornam cada vez mais importantes fatores como rateio de custo (o custo é limitador para muitas iniciativas isoladas), cadeia logística (a eficiência da cadeia depende da eficiência conjunta de todos os seus membros), agilidade (demandas mais especificas e individualizadas, com diminuição contínua do ciclo de vida dos produtos e serviços), e globalização (os mercados deixam de ser apenas locais ou regionais). As características das organizações virtuais também demonstram profundas mudanças em relação às organizações tradicionais. As hierarquias rígidas tendem a desaparecer, pois é necessário o cruzamento de fronteiras organizacionais, para que haja a cooperação de múltiplos especialistas, pertencentes a diversas áreas. As empresas devem se complementar umas as outras com suas competências essenciais. Cada uma entra na rede com sua competência essencial, complementando as demais. O dinamismo é a rotina. Em cada etapa do ciclo de vida do projeto ou serviço, a composição da rede deve variar de acordo com a necessidade e a competência de cada um dos componentes. E ligando tudo isso, há um fluxo continuo e instantâneo de informações, baseado em uma infra-estrutura de tecnologia da informação que permita à organização virtual compartilhar conhecimento e recursos, bem como se adaptar instantaneamente às mudanças do cenário. Assim, as características básicas de uma empresa no contexto das organizações virtuais são:

a) Especialização nas competências essenciais, tornando-se especializadas em determinados conhecimentos;

b) Cooperação pró-ativa, tomando decisões com base nas suas prioridades, mas levando em consideração os parceiros da rede colaborativa;

21

c) Negócios baseados em oportunidades, explorando a velocidade e agilidade típicas das redes de organizações virtuais;

d) Organização virtual por excelência, adotando o uso de recursos de fora da empresa. Entre os conceitos podemos citar escritórios virtuais, tele-trabalho, tele-cooperação e assim por diante;

e) Capacidade de integração, reunindo-se rapidamente a outras empresas para responder à flutuação da demanda.” .

Para mim fica claro que este contexto de dinamismo da organização virtual, aliado a uma demanda elevada de recursos computacionais compartilháveis, tendem a ser um incentivo muito forte para o uso prático dos conceitos de SOA e Grid Computing. Dêem uma olhada nos conceitos de Open Grid Services Architecture – OGSA – em www.globus.org/ogsa para maiores informações.

22

SOA e os CIOs Esta semana estive fazendo palestras em dois eventos com parceiros da IBM. Nos dois o tema foi SOA. Os participantes eram executivos de TI e de linhas de negócio, e está ficando bem nítido para mim a importância que eles estão dando ao assunto. As razões para isso são claras. O mundo de negócios em que vivemos é cada vez mais desafiador. Os limites de tempo e espaço que restringem nosso dia a dia estão desaparecendo. Podemos fazer uma compra ou acessar nosso saldo bancário pela Internet a qualquer hora do dia ou da noite. As mudanças e transformações no cenário empresarial já são uma constante. Conseguir e manter vantagens competitivas sustentáveis depende cada vez mais da capacidade da empresa em ser inovadora em seus produtos, processos e modelos de negócio. Aliás, inovação é considerada estratégica não só para empresas, mas para países. O Fórum Econômico Mundial em 2006 deixou claro esta visão: “The obsolescence of many 20th century structures compels leaders to develop fresh concepts, new institutional models and more-flexible processes for serving diverse populations”. Uma pesquisa que a IBM fez em 2006, chamado “Global CEO Study” , que pode ser acessada em http://www-935.ibm.com/services/us/gbs/bus/html/bcs_ceostudy2006.html?re=bcsceo identificou inovação como o fator que caracterizava as empresas com desempenho acima da média de suas indústrias. Na minha opinião, a próxima onda de investimentos em TI será direcionada para alavancar transformações nas estratégias do negócio. Mas, encontramos uma grande barreira pela frente: as arquiteturas de TI não estão preparadas para permitir às empresas serem ágeis e rápidas o suficiente. Um estudo da McKinsey foi muito contundente quando disse claramente que “as arquiteturas de TI de hoje constituem o maior empecilho que a maior parte das empresas enfrenta quando precisam fazer ações estratégicas” Por que? Aplicações monolíticas, departamentalizadas e embaralhadas em diversas gerações de tecnologias não interoperáveis e até mesmo conflitantes entre si. O resultado é que os processos e modelos de negócio não podem ser modificados ou adaptados dinamicamente. A área de TI responde lentamente ás demandas de mudanças do negócio. Um problema sério são as interfaces entre as aplicações. As ligações hoje são ponto a ponto e a cada nova aplicação, é necessário construir muitas novas interfaces. A proposta do SOA é eliminar este problema (ou elo menos mitigá-lo sensivelmente...). Daí o interesse dos executivos de negócio e de TI na sua adoção. Algumas pesquisas mostram claramente que SOA estás sendo usado inicialmente para resolver os imensos problemas de integração internos, e em um segundo momento as integrações externas, com parceiros de negocio e clientes. Bom, o resumo de tudo isso é que os CIOs e os profissionais de TI devem olhar SOA com atenção. Para maiores informações, além do site DeveloperWorks que vocês já devem acessar regularmente (se não, deveriam...), sugiro acessar também

23

www.ibm.com/soa e adicionalmente ler o SOA World magazine em http://soa.sys-con.com/. E recomendo a leitura de um número específico do IBM Systems Journal dedicado ao assunto, em http://www.research.ibm.com/journal/sj44-4.html .

24

Vamos pensar SOA de forma diferente? Geralmente na nossa maneira de pensar atual imaginamos 20 ou 30 aplicações e quebramos a cabeça pensando em como integrá-las. SOA, é claro, é um caminho para isso. Mas que tal pensarmos de forma diferente? Não mais 20 ou 30 aplicações, mas uma única, que pode ser rearranjada de 20 ou 30 maneiras diferentes para trazer resultados diferentes. O que SOA nos permite fazer? Decompormos o que chamamos de aplicações em suas partes mais elementares (serviços), que podem agora ser recombinadas da maneira mais conveniente. E não devemos nos esquecer que isso só é possível porque temos padrões abertos! Neste futuro contexto, IT passa a ser um agente que favorece e impulsiona mudanças. Como será este cenário de aplicações sendo rearrumadas rapidamente? Primeiro teremos muito mais condições de criar redes de valor colaborativas, pois as empresas poderão mais facilmente integrar seus processos, da forma que for mais adequada para cada oportunidade de negócios. Também veremos uma competição mais acirrada...Pensem: como não teremos mais serviços fechados dentro de padrões proprietários (e difíceis e custosos de serem compartilhados), as barreiras de entrada serão mais baixas. Muitos serviços poderão ser obtidos de fontes externas, o que vai permitir mais empresas adotarem tais serviços mais rapidamente.

Estamos sonhando alto? Uma utopia? Ao falarmos em Utopia, a primeira coisa que nos vem em mente é algo irrealizável, inatingível. De fato, se formos buscar o significado da palavra Utopia encontraremos “Projeto irrealizável; quimera.”. Mas, se pensarmos diferente, a utopia pode favorecer uma visão crítica da realidade. A utopia também pode ser uma forma de ação, uma vez que provoca o movimento das pessoas (e das empresas). Portanto pode ser um instrumento de transformação. E citando uma frase que li algum tempo atrás: "O presente pertence aos pragmáticos. O futuro é dos utopistas"! .

25

Estamos preparados para SOA? Há alguns dias um colega meu, CIO de uma grande empresa me perguntou “como poderei saber se estou ou não preparado para SOA?”. A pergunta gerou um debate interessante, que gostaria de compartilhá-las com vocês. Bom, antes de mais nada acordamos em um ponto: SOA tem tudo a ver com processos de negócios. Processos de negócios são atividades que geram valor para a organização, seus stakeholders e clientes. Por exemplo, é através dos processos de negócios que a organização entrega produtos e serviços aos seus clientes. Claro que em mundo cada vez mais informatizado, estes processos de negócios são suportados por software e, portanto, o conceito de SOA vai precisar de tecnologia para ser implementado. Mas, a tecnologia é meio e não fim! Também concordamos que a estratégia SOA deve estar relacionada com objetivos de negócio, como possibilitar que a empresa tenha maior agilidade e rapidez às demandas do mercado, tornando os processos de negócio mais adptáveis à estas mudanças. Depois analisamos como uma empresa “vê” sua TI. Fizemos uma análise simplista, classificando as empresas em três níveis de maturidade de TI. No primeiro, TI é vista como fornecedora de infra-estrutura, atuando basicamente no nível operacional, focada em custo, sendo “invisível” à organização. Em um nível mais avançado TI é vista como facilitadora. Neste nível já existe um forte preocupação com governança e há reconhecimento do papel de TI pelos executivos pares do CIO dentro da organização. E finalmente, em um estágio mais avançado, TI é vista como agente de inovação, contribuidora pró-ativa para as estratégias do negócio. O CIO é considerado como o “consultor” do CEO. Se a área de TI estiver no terceiro e mais avançado nível, estará, sem sombra de dúvida preparado para SOA. Se estiver no segundo nível, existirá grande potencial para adoção de SOA, mas é necessário uma maior preparação da própria organização. E se estiver no primeiro nível, SOA ainda está meio longe...Tem um trabalho maior pela frente, mas pode ser um primeiro passo na direção de estar mais afinado com o negócio e menos encastelado na tecnologia. Ok, e como posso saber em que nível a empresa estará? Que tal analisar quanto tempo e energia o CIO gasta com sua equipe, com seus pares e o ecossistema de fornecedores de tecnologia, e com o CEO e o board da organização? Se ele estiver dedicando a maior parte do tempo com sua equipe, provavelmente estará focado mais intensamente nas questões técnicas, preocupado quase que exclusivamente com custo, envolvido no dia a dia da operação. É uma organização de TI focada na tecnologia e SOA será visto como mais uma implementação tecnológica descolada do contexto do negócio. Provavelmente terá pouco apoio e comprometimento dos demais executivos. Poucas chances de sucesso se continuar focado na tecnologia!

26

Bem, e se o CIO estiver dedicando um tempo maior aos seus pares e ao ecossistema de fornecedores de tecnologia? Este é o estágio típico das organizações consideradas como facilitadoras do negócio. São bem avaliadas pelos demais executivos de negócios, são bem consideradas pelos fornecedores de tecnologia, mas ainda sim os altos executivos não consideram a área de TI como alavancadora de inovações ou contribuidoras para a estratégia do negócio. Ela é vista como responsiva às demandas, mas não pró-ativa em inovações e geração de novas oportunidades de negócio. Neste estágio SOA tem espaço, mas é necessário um trabalho mais intenso de aproximação com as linhas de negócio para conseguir seu comprometimento. A estratégia SOA deve estar direcionada à agenda dos objetivos do negócio, como acelerar as respostas à novas oprtunidades ou riscos/ameaças, inovação em produtos e serviços, otimização da cadeia logística e assim por diante. SOA pode ser a passagem de ida para um nível mais avançado. E as organizações de TI mais avançadas? Neste estágio o CIO já está participando e colaborando nas decisões estratégicas. SOA será naturalmente visto como estratégia de inovação para o negócio. É um estágio onde os altos executivos não falam em IT (Information Technology) mas em BT (Business Technology). É o Nirvana dos executivos de TI... Assim, a resposta virá de uma auto-análise. A sugestão é faça uma pulsologia e identifique onde você está. Trace sua rota e vá em frente! Ah, em tempo, meu amigo se classificou no segundo estágio!

27

Capacitação em SOA Um tema que merece conversarmos um pouco é a capacitação em SOA. Volta e meia debatemos o assunto com CIOs e arquitetos e este assunto aparece nas nossas conversas. Como todo conceito novo, existem muitas e muitas definições, além de variações dos próprios conceitos. Recente pesquisa mundial do IDC, entre mais de 700 desenvolvedores mostrou que ainda existe muita confusão em conceitos e percepções sobre SOA. Dos pesquisados, apenas 6,2% disseram que tem uma boa compreensão dos conceitos SOA. Portanto SOA ainda é desconhecido. Muita gente confunde SOA com Web Services, mas, no meu entender, ninguém discorda que a capacitação adequada em SOA é fundamental para termos sucesso na sua implementação. SOA apresenta desafios interessantes: não envolve apenas tecnologia, mas demanda muito de negócios. O objetivo de uma estratégia SOA não é implementar SOA, mas, por exemplo, melhorar a flexibilidade do negócio. Além disso é um alvo em movimento, com novos produtos, “best practices” e metodologias aparecendo a cada instante. O resultado prático é que o que precisaremos saber amanhã não é o que precisamos saber hoje... Bem, vamos tentar fatiar o elefante. Criar um plano de capacitação em SOA depende de inúmeros fatores. Um é a maturidade e o “starting point” da organização frente a SOA. Se o “starting point” for construir Web Services em cima de aplicações desconectadas a exigência de treinamento será diferente de um “starting point” focado em integração externa, envolvendo parceiros e clientes A estratégia SOA da organização também é um fator influenciador na criação do plano de treinamento. Sem uma visão de longo prazo ficarão faltando peças que mais tarde vão fazer sentir sua ausência. Outro aspecto a ser considerado é a diversidade do público alvo: arquitetos, desenvolvedores e gestores não precisam e nem devem ter o mesmo tipo de treinamento. Os desenvolvedores estão mais focados nas tecnologias, os gestores nas estratégias e road maps, e os arquitetos nas teorias e conceitos. Onde conseguir informações? Existem fornecedores de tecnologias como a IBM, que disponibilizam muitas informações, como vocês poderão ver acessando www.ibm.com/soa e http://www.ibm.com/developerworks/webservices . Vocês podem também usar search engines como o Google e o Yahoo. Existem milhões de documentos e uma simples busca me trouxe 33.700.000 documentos no Google e 37.800.000 no Yahoo. Claro que tem muita besteira aí, inclusive outras coisas chamadas SOA (School of Américas, por exemplo)... Existem também sites especializados, como o SOA Institute, www.soainstitute.org e vários livros muito bons. Alguns que recomendo são: “The New language of Business: SOA & Web 2.0”, de Sandy Carter, “Service-Oriented Architecture (SOA): A Planning and Implementation Guide for Business and Technology”, de Erick A. Marks e Michael

28

Bell, e “Service-Oriented Architecture (SOA): Concepts, Technology, and Design”, de Thomas Erl. Na Amazon vão aparecer vários outros livros sobre o assunto. E depois dos treinamentos? Que tal pensar em workshops que identifiquem e analisem as oportunidades de implementar SOA na empresa? Como vemos, temos muita coisa a fazer. O importante é sair da inércia e ir em frente.

29

Apresentando SOA no CIO Executive Day em Curitiba Julho de 2007: bem no meio de curtas férias fiz uma palestra no CIO Executive Day, em Curitiba. É um evento bem interessante e que terá sequencia na semana que vem em Porto Alegre. Caso queiram ver detalhes do evento acessem www.cioexecutiveday.com.br . Minha palestra foi “Inovação em TI: criando diferencial competitivo”, onde procurei mostrar a importância da inovação para o sucesso de qualquer empresa e como é fundamental que a área de TI esteja sendo vista como contributiva para este processo. Vivemos em um cenário de negócios cada vez mais desafiador e precisamos estar constantemente inovando, não apenas criando novos produtos, mas gerando novos processos e mesmo novos modelos de negócio. Há uma frase bem emblemática deste contexto, que foi publicada em um artigo da Harvard Business Review (“The Quest for Resilience”), onde os autores dizem “In the past, executives had the luxury of assuming that business models were more or less immortal. Companies always had to work to get better...but they seldom had to get different, not at their core.” Hoje está nítido que a preocupação com inovação é cada vez maior, e alguns analistas de indústria já afirmaram:

a) Gartner Group, no 2006 Annual CIO Survey: “competitive advantage, revenue growth and faster innovation all among their top 10 business issues”;

b) Deloitte and Touche Global Benchmark Study of Manufacturers: “By 2010, products representing more than 70% of today´s sales will be obsolete due to changing customer demands and competitive offerings”;

c) World Economic Forum 2006: “The obsolescence of many 20th century structures compels leaders to develop fresh concepts, new institutional models and more-flexible processes for serving diverse populations”.

O estudo que a IBM realizou com 750 CEOs (“ The Global CEO Study 2006” ) mostrou que “ 65% expect to radically change their companies during the next 2 years”. Fica claro que inovação, acompanhada por mudanças fundamentais nos processos e modelos de negócio é o melhor caminho para o crescimento sustentável. Isto significa que a próxima onda de investimentos em TI será direcionada a alavancar transformações nas estratégias do negócio. Inovação não é implementar ERP. Isto já é commodity...Ter um ERP é necessidade básica para a empresa se manter à tona. Mas não cria diferencial competitivo. Um fórum que a IBM organizou no ano passado, “IBM CIO Leadership Forum”, em Monte Carlo, Mônaco, mostrou que, no entendimento dos CIOs presentes, a globalização, a complexidade crescente nos negócios e mudanças cada vez mais rápidas no cenário

30

econômico e empresarial estão transformando as bases dos atuais modelos de negócio e para eles “IT is the lifeblood that enables this transformation” . Este fórum mostrou que 84% dos CIOs presentes acreditam que a tecnologia está transformado substancialmente suas indústrias e alavancando vantagens competitivas. 78% dos CEOs (pelo “Global CEO Study” da IBM) também acreditam que a integração entre o business e TI seja fundamental para inovação, mas entendem que há uma brecha significativa entre o nível desejado e o real quando se fala nesta integração. E porque TI não tem sido tão inovadora quanto poderia ser? Várias razões contribuem para isso, como um excessivo foco no dia a dia, manter uma posição mais passiva, esperando que os executivos de negócio direcionem as ações de TI ou mesmo um viés tecnológico, considerando a tecnologia como a solução para todos os problemas. Além disso, em muitas organizações TI ainda é vista como suporte, focada na automação de tarefas e manutenção da infra-estrutura tecnológica. Não são muitas as empresas que já olham TI como business, a encarando como fonte geradora de receitas e maximizadora de oportunidades de negócio. Mas além de debater esta problemática do posicionamento estratégico de TI na organização, abordei algumas tendências tecnológicas que poderão contribuir em muito para alavancar o poder de inovação da área de TI. Mais precisamente abordei Web 2.0 e SOA, e a junção entre estes dois mundos. Na verdade Web 2.0 e SOA são o mesmo lado de uma moeda e apesar de terem origens diferentes (Web 2.0 começou fora das empresas) e SOA, dentro das corporações, o seu pleno potencial será alcançado quando forem integradas. Imaginem um cenário de aplicações mashup, criadas por clientes e parceiros de negócios, acessando serviços internos à corporação, através de SOA. O limite da inovação será a criatividade dos atores do ecossistema! Bem e um dos pontos altos de qualquer evento é troca de idéias no café ou, no caso deste, no coquetel de encerramento. E, entre um vinho e outro, me perguntaram, “Ok, gostei do papo sobre SOA, mas como medir o ROI desta iniciativa?”. Para responder é melhor mostrar primeiro o que é SOA. É um conceito simples, que é dissolver suas aplicações em “building blocks”, (serviços) que podem ser infinitamente rearranjados. Imaginem o conhecido brinquedo Lego, onde com as mesmas peças vocês podem construir diversos objetos. Cada peça destas é um serviço SOA e os objetos são as novas aplicações. Criar ou transformar um novo processo de negócios nos leva, no âmbito de TI, a rearrumar os serviços de TI que suportam as atividades destes processos. Não existem demoras em escrever novas aplicações ou alterar dezenas ou centenas de programas em linguagens diferentes. Como medir o benefício desta maior velocidade e menor time-to-market (leia-se flexibilidade) de responder às dinâmicas do mercado? De lançar produtos e processos inovadores antes da concorrência? De qualquer maneira, embora não seja fácil medir o ROI de uma nova tecnologia, podemos sistematizar o processo, identificando benefícios potenciais, estimando um primeiro cenário de custos, calculando o retorno inicial, e

31

calculando o retorno para as implementações subseqüentes, uma vez que SOA produz benefícios crescentes à medida que se entranha na organização. Para um estudo mais aprofundado de se chegar ao ROI de SOA, recomendo a leitura de um paper (SOA, a Practical Guide to Measuring Return on that Investment) publicado pelo IBM Institute for Business Value, em http://www-05.ibm.com/il/services/pdf/SOAmeasuringreturn.pdf .

32

Outro CIO Executive Day, agora em Porto Alegre Em agosto de 2007 estive em Porto Alegre, participando de outra edição do CIO Executive Day. Repeti nos pampas a palestra “Inovação em TI: criando diferencial competitivo”, onde procurei mostrar a importância da inovação para o sucesso de qualquer empresa e como é fundamental que a área de TI esteja sendo vista como contributiva para este processo. Um dos temas principais foi SOA. Porque este tema é tão debatido? Está claro para todos nós que a flexibilidade do negócio depende da flexibilidade de TI. Infelizmente, na maioria das vezes as arquiteturas de TI das empresas não são flexíveis o suficiente. Por que? No decorrer de várias décadas os sistemas foram implementados sem uma visão integrada, ocasionando hoje grandes problemas de integração. São várias gerações de tecnologias diferentes convivendo umas com as outras. O resultado é que uma grande parcela dos esforços e energia (e investimentos) de TI são consumidos pelas atividades de manutenção e integração. Integração é uma atividade sem fim. Como de maneira geral as ligações entre aplicações são ponto a ponto, o trabalho é imenso. Imaginem que temos 10 aplicações que precisam ser conectadas umas as outras. A fórmula para estimar o número de ligações é simples: n(n-1)conexões. Ora, fazendo a conta vemos 10*9 = 90 conexões a serem feitas, cada uma delas tendo que entender as características internas da outra aplicação. Coloquem mais uma aplicação no bolo e temos a explicação porque este trabalho dura ad infinitum! Se a empresa precisar criar ou mudar processos de negócio, vai sentir na pele o problema: TI responde lentamente, pois para mudar processos, diversas aplicações devem ser modificadas. Fica fácil de explicar porque em muitas organizações o relacionamento de TI com as áreas de negócio é tão conturbado. E qual é a proposta da SOA? Mudar este contexto, dissolvendo as aplicações em “building blocks”, (serviços) que podem ser infinitamente rearranjados. Imaginem o conhecido brinquedo Lego, onde com as mesmas peças vocês podem construir diversos objetos. Cada peça destas é um serviço SOA e os objetos são as novas aplicações. Criar ou transformar um novo processo de negócios nos leva, no âmbito de TI, a rearrumar os serviços de TI que suportam as atividades destes processos. Não existem demoras em escrever novas aplicações ou alterar dezenas ou centenas de programas em linguagens diferentes. Daí o grande interesse que SOA vem despertando entre os CIOs. As pesquisas refletem este quadro. Uma delas, feita pelo Aberdeen Group (What CIOs Should Know About SOA) mostra que os Top 3 impulsionadores para SOA são Development of new capabilities (50%), Managing IT complexity (44%).e re-usage of apps via Web services (43%). Outra pesquisa, esta efetuada pelo Forrester Research em abril de 2006, para a pergunta “Como SOA está sendo usada”, teve como resposta integração interna com 83%, seguida

33

de integração externa e já aparecendo, para as grandes corporações, transformação do negócio com 46%. Com SOA estamos dando um grande passo de evoluir de IT para BT (Business Technology), com TI se tornando parte essencial e estratégica dos negócios da empresa. Portanto, SOA não deve ser ignorado ou subestimado.

34

SOA, Web 2.0 e aplicações mashup Aplicações mashup começam a despertar bastante atenção. Já vemos muitos eventos debatendo o tema e um evento que vale a pena participar é o MashupCamp, que vai ocorrer em setembro na Europa (http://www.mashupcamp.com/). A IBM é patrocinadora deste evento. Aliás, estamos investindo intensamente neste conceito. Vejam a iniciativa IBM Mashup Hub no Alphaworks, acessando http://services.alphaworks.ibm.com/mashuphub/. Aplicações mashup estão no cerne do modelo Web 2.0. As primeiras aplicações mashup que apareceram, muitas delas usando Google Maps, ainda são a ponta do iceberg. Nós estamos dando os primeiros passos em um novo mundo, onde usuários e parceiros de negócios desenvolverão aplicações em cima das nossas próprias aplicações. Mas, para fazer isso, precisamos adotar o conceito de visualizar nossas aplicações como plataformas, onde o mundo externo poderá acessá-las via APIs abertas e publicadas. Se olharmos com atenção, veremos, na prática, que estamos falando da junção dos mundos SOA e Web 2.0. Bem, vou explicar melhor... Para começar vamos ver alguns casos práticos. Começando com o eBay. Quando o eBay foi criado, a chave para o sucesso do comércio eletrônico era criar um site na Web. Com este modelo o eBay tornou-se um dos maiores sucessos da era da Internet. Mas, hoje, a ação está onde os usuários a criam, ou seja, em páginas de relacionamento MySpace, em vídeos no YouTube ou em seus blogs. Portanto, para o eBay se manter bem sucedido, tem que estar em todos estes lugares. Como fazer isso? Abrindo APIs que ofereçam serviços que permitem às pessoas comprar itens do eBay fora de seu site central. Por exemplo, permitir acessar o eBay de dentro do Facebook ou MySpace. Nas declarações de seus executivos, nos recentes eventos para investidores ficou claro a estratégia futura: o eBay não será apenas um site, mas um provedor de serviços que reforce o comercio eletrônico em toda a Internet. Outro exemplo é a Amazon. O seu fundador e CEO, Jeff Bezos, disse recentemente: “We´re all building this thing together”, ao comentar a estratégia da empresa em incentivar desenvolvedores externos a acessarem os serviços da Amazon e os embutirem em outros sites e aplicações. E embora muitas empresas ainda tenham receio de abrir seus dados proprietários, a Amazon é clara: “The more data that we’re able to put in the hands of external developers, the more interesting tools, sites, applications will be built, and the more of those that exist, the greater the return to Amazon. We’re going to see more traffic, more clicks, and ultimately we’ll see more purchases. So it’s definitely not like a science experiment”. Querem um terceiro exemplo? Google! Abrindo APIs para suas aplicações, incentivam a inovação e novas aplicações. Um executivo do Google disse recentemente: “We expect new and creative ideas to come out of this that we haven´t thought of yet”. Que estas empresas estão fazendo? Abrindo seus sistemas via APIs para que parceiros externos criem novas e inovadoras aplicações, integrando os processos de negócios. O acesso às

35

APIs Google Maps pode ser enncontrado em www.google.com/apis/maps/ . Mais ainda? Bem, que tal olhar o Zillow.com (www.zillow.com) ou a JetBlue Airways, onde seus passageiros podem acompanhar a posição do avião, usando GoogleMaps, na tela de seu assento, sintonizando o canal 13. Aliás a JetBlue permite a cada um acompanhar a situação de cada vôo em tempo real, acessando seu site (www.jertblue.com) e clicando nas opções Manage your flights/Track a flight. Que nem aqui... E, para não cansar, um último exemplo... Vejam o AccuWeather (www.accuweather.com), que implementa aplicações mashup usando a tecnologia QEDWiki da IBM. Vejam em http://www-03.ibm.com/press/us/en/pressrelease/20731.wss e http://www-03.ibm.com/developerworks/blogs/page/Turbo?entry=today_s_weather_mashed_up. Também tem um video interessante no YouTube sobre o uso desta tecnologia, que pode ser acessado em http://br.youtube.com/watch?v=ckGfhlZW0BY. Bem, e se quiserem dar uma olhada nas inúmeras APIs para Web 2.0 disponíveis, visitem //programmableweb.com. Vale a pena. Qual é a mensagem que estes exemplos estão nos passando? Abram suas plataformas de negócios para incrementar a velocidade, escopo e ritmo da inovações. Manter as aplicações fechadas vai restringir a inovação aos limites de criatividade da sua própria equipe de profissionais. E isto não se aplica apenas ao Google, Amazon ou eBay, mas a bancos, empresas aéreas, seguradoras, industrias automotivas, órgãos públicos (que tem imensas bases de dados, muitas vezes subutilizados pela sociedade), etc, etc, etc... OK, mas como colocar estas idéias em prática? De um lado temos as comunidades com tecnologias que permitem criar aplicações mashup. Mas do lado da empresa? Como abrir APIs para a parafernália de aplicações com problemas de integração e diversidades tecnológicas? A resposta, no meu entender, está na proposta do SOA. Porque não criar uma camada, que chamaremos de plataforma de negócios, em cima das aplicações da empresa? Esta plataforma abriria à comunidade de usuários e parceiros de negócios os serviços que as aplicações internas oferecem (quando falamos em aplicações, falamos em processos de negócios) via APIs abertas e publicadas. A plataforma se encarregará de acessar as aplicações internas, sejam elas novas, ou legadas, estas encapsuladas, via SOA, expondo-as publicamente. Ou seja, desenhamos dois componentes na arquitetura de aplicações da empresa: uma voltada para interação com os usuários (a plataforma aberta, acessada por APIs, permitindo aos usuários criarem suas aplicações mashup) e outra, para suportar internamente os serviços de negócios. A camada de serviços de negócio é constituída de componentes ou aplicações que implementam os processos de negócio. A cola entre estes dois mundos é SOA. Fácil de visualizar, não é? O difícil é colocar em prática. Desenvolver aplicações para

36

Web 2.0, que são por natureza dinâmicas e baseadas no conceito de serviços, demanda muitos ajustes nas técnicas e processos de desenvolvimento de software que as empresas atualmente adotam. Demanda novos skills de programação, com ênfase em Ajax (www.openajax.org) e scripting languages, como Perl, PHP, Python e Ruby. Exige técnicas (lightweight ou simplified programming models) e processos de desenvolvimento mais rápidos (Agile Software Development). Uma introdução superficial ao assunto pode ser vista em http://en.wikipedia.org/wiki/Agile_software_development. E demanda também um cuidado muito maior nos projetos de interfaces com os usuários. Não se chega lá de um dia para o outro, mas se compreendermos as vantagens competitivas desta estratégia, que nos abrirá explorar inúmeras oportunidades de inovação, temos que começar logo a dar os primeiros passos. Porque não pensar em SOA como estratégia de transformação dos negócios, acoplando-a ao conceito da Web 2.0 e aplicações mashup? Fica aqui a idéia para uma reflexão mais ampla.

37

SOA e a comunidade Apache Muitos dos projetos da comunidade Apache estão sendo direcionados para SOA. A sua arquitetura altamente componentizada, com componentes plugáveis, facilita a construção de projetos orientados à SOA.Se analisarmos uma plataforma hipotética voltada a SOA, vamos identificar alguns macro componentes, como uma “core platform” que pode ser considerado a base para execução e integração dos serviços, um “service delivery bus” para roteamento de mensagens e transações, “configuration services”, que organiza a montagem dos componentes em serviços e uma plataforma de comando, para fornecer serviços de grenciamento e governança. Os projetos SOA desenvolvidos em torno do Apache atendem a esta plataforma genérica. Por exemplo, os projetos Geronimo e Tomcat são voltados para as funções de “core platform”. Em “configuration services” destaca-se o projeto Tuscany. Como “service delivery bus” temos o Synapse e o ServiceMix. Enfim, vale a pena investir algum tempo analisando os diversos projetos SOA do Apache. Tem muita coisa extremamente interessante. E voltando ao IBM Developerworks, vocês vão ver que a IBM está atuando intensamente em vários destes projetos, como Ant, Cocoon, Excalibur, Geronimo, James e Tuscany, entre outros. O WebSphere Community Edition (http://www-306.ibm.com/software/webservers/appserv/community/) é baseado na tecnologia Apache, incluindo o Geronimo e o Tomcat, além de plugins Eclipse e banco de dados Cloudscape. Pode ser baixado “for free” do site da IBM (veja acima). Na minha opinião, a adoção do Apache http Server, Geronimo e Tomcat por uma empresa como a IBM é um sinal inequívoco que o modelo Open Source é sério e que os projetos oriundos da comunidade Apache são projetos altamente profissionais. Mas vale a pena falar de um outro projeto extremamente interessante, que é o Tuscany. O Tuscany implementa um modelo de implementação SOA chamado de SCA (Service Component Architecture). A proposta da especificação SCA é simplificar o desenvolvimento de aplicações SOA, facilitando o desenvolvimento de componentes. Para isso cria um modelo para construção de componentes independente de linguagens de programação e facilita a construção de aplicações compostas, que podem ser “montadas” a partir destes componentes (lembram-se do jogo Lego?). A IBM vem enfatizando SCA. Já temos suporte no WebSphere ESB (vejam http://www.redbooks.ibm.com/abstracts/sg247406.html) e apoiamos fortemente o projeto Tuscany. O URL do projeto Tuscany está em http://incubator.apache.org/tuscany/ . Para maiores informações sobre SCA acessem o site da Open SOA Collaboration (http://www.osoa.org/display/Main/Home), grupo formado por diversas empresas, como IBM, BEA, Sun, RedHat e outras, e como dito em seu site, “The Open SOA Collaboration represents an informal group of industry leaders that share a common interest: defining a language-neutral programming model that meets the needs of

38

enterprise developers who are developing software that exploits Service Oriented Architecture characteristics and benefits.”. Tem um documento sobre conceitos de SCA que recomendo seja lido: “Introducing SCA”, que vocês poderão acessar em http://www.davidchappell.com/articles/Introducing_SCA.pdf Na minha opinião, todo desenvolvedor que está buscando implementar soluções SOA deve acompanhar de perto a especificação SCA e os projetos que lhe dão suporte. O Tuscany é um bom exemplo. Ele pode ser encarado como um indicador do nível de desenvolvimento prático da especificação. Bem, e para terem muitas outras informações adicionais sobre SCA e o projeto Tuscany, acessem o blog de meu colega da IBM, Luciano Resende em http://lresende.blogspot.com e também em http://www-03.ibm.com/developerworks/blogs/page/lresende. Em tempo, a especificação da SCA já foi encaminhada à OASIS, em março deste ano, para ser validada, evoluída e distribuída como um padrão aberto. A OASIS já mantém os padrões de Web Services, como UDDI, WSDL, SOAP e WS-* e agora com SCA/SDO (System Data Objects) oferece os fundamentos arquitetônicos para construção de aplicações SOA. Interessante que entre as empresas que incentivam e apóiam a iniciativa SCA não encontramos a Microsoft, que optou, mais uma vez, por não adotar padrões abertos. Bem, talvez em algum dia a pressão do mercado a obrigue a tornar o .NET um padrão aberto... OK, e aqui está o press release: “Leading Technology Vendors Announce Completion of Specifications Designed to Simplify SOA Application DevelopmentOpen SOA Collaboration Chooses OASIS to Advance SCA and SDO Specifications March 21, 2007 – Eighteen leading technology vendors focused on driving technology initiatives supporting the creation of industry standards around service oriented architectures (SOA), today announced that key Service Component Architecture (SCA) and Service Data Objects (SDO) specifications have completed incubation and will be formally submitted to OASIS for advancement through its open standards process. The SCA specifications are designed to help simplify the creation and composition of services, critical to building applications using services based on an SOA approach. With these SCA specifications now mature, the partners intend to turn over their standardization process to OASIS. Additionally, the partners have completed work on the SDO specifications, designed to enable uniform access to data residing in multiple locations and formats, and will turn over stewardship of SDO/Java work to the Java Community Process and non-Java (C++) work to OASIS. The SCA and SDO specifications can help organizations to more easily create new and transform existing IT assets, enabling reusable services that may be rapidly assembled to

39

meet changing business requirements. These specifications greatly reduce complexity associated with developing applications by providing a way to unify services regardless of programming language and deployment platform. Both are technologies designed to simplify the representation of business logic and business data. Early customers are already implementing and gaining value. “We applaud the Open SOA Collaboration for reaching this milestone and for choosing to take the next step and advance this important work through an open standards process,” said Patrick Gannon, president and CEO of OASIS. “We look forward to furthering the evolution of SCA from specifications to standards and to promoting the broadest possible industry adoption through education and implementation efforts.” Since November 2005, 18 companies have joined the effort to work on new industry specifications aimed at simplifying SOA application development. Partner companies include BEA Systems, Cape Clear, IBM Corporation, Interface21, IONA, Oracle, Primeton Technologies, Progress Software, Red Hat, Rogue Wave Software, SAP AG, Siemens AG, Software AG, Sun Microsystems, Sybase, TIBCO Software, and Xcalia. Together, these companies have achieved significant progress around SCA and SDO specifications. The partners will continue to incubate and drive technology initiatives focused on simplifying SOA application development. Additionally, the group’s vendor-neutral Web site (www.OSOA.org) will continue to serve as an information resource for access to draft specifications and white papers, and provide a forum for industry input and feedback. About OASISOASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards. The consortium produces more Web services standards than any other organization along with standards for security, e-business, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 5,000 participants representing over 600 organizations and individual members in 100 countries. For more information, visit www.oasis-open.org. About Open SOAThe Open SOA Collaboration represents an informal group of industry leaders that share a common interest: defining a language-neutral programming model that meets the needs of enterprise developers who are developing software that exploits Service Oriented Architecture characteristics and benefits. The Collaboration is not a Standards Body; it is a set of vendors who wish to innovate rapidly in the development of this programming model and to deliver Specifications to the community for implementation. These specifications are made available to the community on a Royalty Free basis for the creation of compatible implementations. When mature, the intent is to hand these specifications over to a suitable Standards Body for future shepherding. For more information, visit www.osoa.org.”.

40

Um pouco de SCA Há poucas semanas escrevi um post abordando SCA (Services Component Architecture) e o projeto Tuscany (http://www-03.ibm.com/developerworks/blogs/page/ctaurion?tag=SCA). Neste post sugeri acessar o site www.osoa.org, que representa o grupo de empresas (IBM é uma delas) que está suportando o desenvolvimento da SCA, bem como forneci o link para o projeto Tuscany, que pode ser acessado em http://incubator.apache.org/tuscany/.

Também sugeri a leitura de um paper muito interessante e inicial sobre o assunto, “Introducing SCA”, de David Chappell (http://www.davidchappell.com/articles/Introducing_SCA.pdf), onde ele faz uma afirmativa categórica: “Anyone who´s interested in the future of application development should also be interested in SCA”.

Bem, de lá para cá recebi alguns emails, solicitando mais informações sobre SCA. Aqui vão elas:

A especificação SCA foi remetida à organização Oasis (http://www.oasis-open.org/), para continuar sendo evoluído, de forma aberta e transparente. A proposta da organização é bem clara: “OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society. The consortium produces more Web services standards than any other organization along with standards for security, e-business, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 5,000 participants representing over 600 organizations and individual members in 100 countries”.

O projeto SCA na Oasis pode ser acessado em http://www.oasis-opencsa.org/. Reparem que SCA mudou para CSA, de OASIS Open Composite Services Architecture (CSA). Sua proposta é simples: “advances open standards that simplify SOA application development. Open CSA brings together vendors and users from around the world to collaborate on standard ways to unify services regardless of programming language or deployment platform. Open CSA promotes the further development and adoption of the Service Component Architecture (SCA) and Service Data Objects (SDO) families of specifications”.

Consegui também algumas dicas com um colega da IBM EUA, Doug Tidwell, que vou compartilhar com vocês. Ele sugere a leitura do livro “SOA for the Business Developer: Concepts, BPEL and SCA”, de Ben Margolis. Também sugere uma lista de papers disponíveis no site developerWoks, como:

1) SCA Application Development (parte 1 & 2) : An overview of SCA, acessado em http://www-128.ibm.com/developerworks/webservices/library/ws-soa-scadev1/ e http://www-128.ibm.com/developerworks/webservices/library/ws-soa-scadev2/ .

41

2) Building SOA Solutions with SCA (4 partes), http://www.ibm.com/developerworks/websphere/techjournal/0510_brent/0510_brent.html

3) Java SCA invocation styles: http://www-128.ibm.com/developerworks/webservices/library/ws-soa-scajava/

4) Using PHP´s SCA and SDO extensions: http://www-128.ibm.com/developerworks/webservices/library/ws-soa-scasdo/

5) Introduction to Service Data Objects: http://www-128.ibm.com/developerworks/webservices/library/j-sdo/

E também recomenda acessar http://pecl.php.net/package/SCA_SDO para implementação do SCA/SDO em PHP. Ok, acho que para começar o jogo temos bastante coisa para se ler e desenvolver. Mãos à obra!

42

Previsões para 2008: Como ficará SOA? Estamos chegando o final do ano de 2007...É impressão minha ou os anos estão passando cada vez mais rápido? Bem, de qualquer modo, como muita gente faz, vou também me atrever a fazer algumas “previsões” para 2008!!! Sim, é hora da chutorologia... Para mim em poucos anos o termo IT (Information Technology) será substituído por BT (Business Technology), uma vez que cada vez mais TI estará inserido nos negócios, se tornando parte integrante dos negócios, gerenciado pelas linhas de negócios e até mesmo tendo seus budgets definidos e alocados pelas linhas de negócio. Com isso o perfil dos executivos e profissionais de IT, desculpem BT, penderá mais para business e menos para expertise em tecnologia. Temos que começar a rever os currículos dos cursos de graduação... OK, e em termos de tendências, acredito que devemos prestar mais atenção à SOA/BPM (SOA sem BPM estará incompleto), Web 2.0 e suas aplicações mash-up, Open Source e virtualização. Bem, Web 2.0 e as aplicações mash-up deverão sair do campo da “curiosidade” para entrar no budget das empresas. Aliás, há um ano pouca gente sabia o que eram aplicações mash-up...As coisas estão indo bem rápido e vamos começar a ouvir falar mais em Enterprise 2.0, que poderá ser uma melhor aproximação do uso dos conceitos e tecnologias da atual Web 2.0 dentro do cenário corporativo. É um tema que merece um post específico e vou escrevê-lo em breve. SOA é a resposta ao imenso problema da falta de flexibilidade e agilidade que encontramos hoje nas nossas aplicações monolíticas e pouco integradas. Creio que vamos finalmente entender que SOA e BPM (Business Process Management) são complementares e provavelmente serão um dos principais itens da agenda dos CIOs para os próximos anos. Aliás, BPM é uma disciplina de negócio e não de tecnologia. Mas, sem tecnologia não conseguimos fazer com que os conceitos de SOA/BPM se concretizem. Open Source tem provocado impactos significativos na indústria de software e começamos a ver claros sinais de amadurecimento do mercado. Já não é mais um bicho-de-sete-cabeças, começando a fazer parte integral do portfólio de software das empresas. Ter Linux, MySQL, Eclipse e Apache dentro de casa já não assusta mais nenhum CIO...Vejam em outros posts do blog a estratégia da IBM em Open Source. Pesquisem a tag (categories) OpenSource. Vale a pena. E temos a virtualização...Não é uma tecnologia nova, pois começou no mainframe IBM 360/67, que apareceu em 1967. Ou seja, há 40 anos atrás! Para mim virtualização vai muito além da consolidação. O conceito de virtualização comoditiza diversos outros segmentos. Por exemplo, posso usar um conjunto de discos

43

mais baratos para compor uma solução mais confiável que a oferecida por um único dispositivo, mais caro. Mas, interessante, a tecnologia de virtualização vai devorar a si mesmo...Vejam: o próprio setor também caminha rápido para comoditização, com excelentes soluções de software baseadas em Open Source, como o Xen, que, provavelmente, em breve estarão embutidos no firmware ou nos próprios sistemas operacionais. Assim, no futuro breve, para implementar virtualização não será necessário adquirir um software específico. A solução já virá dentro dos servidores. E que outros impactos a virtualização nos trará? Segundo o IDC, seu crescente uso tenderá a reduzir as previsões de venda de servidores baseados em plataforma x86 em até 4,5 milhões de unidades, em um horizonte de tempo até 2011. Para terminar, que tal olharmos o outro lado? Aqui está uma pequena lista de tecnologias que não decolaram...Para nos lembrar que nem sempre as previsões funcionam! Vejam em http://www.news.com/8301-10784_3-9827095-7.html.

44

Janeiro de 2009: nosso último post sobre SOA! Há algum tempo que não escrevia nenhum post sobre SOA. E eis que surgiu a oportunidade. Um bate papo com um colega no restaurante da IBM, na sede da Pasteur, no Rio, que tem uma bela vista para a enseada de Botafogo. Que me desculpem os colegas de sampa, mas lá eles só tem vista para a avenida 23 de Maio! Mas o papo surgiu quando debatiamos o efeito da retração econômica nos investimentos de TI e mais especificamente em SOA. Uma retração econômica afeta ou não investimentos em SOA? Bem, qualquer retração econômica faz com que a maioria dos investimentos se concentrem em redução de custos e em projetos de retorno rápido. Os projetos SOA não podem ficar descolados do mundo real. Em tempo bicudos, devem entregar soluções de negócio de resultados rápidos. Aliás, um erro muito comum é dizer coisas como “este ano minha estratégia é implementar SOA”. O objetivo não deve ser implementar SOA, mas sim implementar melhorias nos resultados do negócio e SOA é meio para isso. SOA não pode e nem deve ser um fim em si mesmo. E um comentário...Como SOA permite tornar a empresa mais flexível, a própria estratégia de SOA deve ser flexível. Isto implica que se o momento fizer com que os executivos estejam antenados com redução de custos, os projetos SOA devem prioritariamente enfatizar este potencial de redução de custos. Os projetos com retorno mais no longo prazo podem ser postergados. Uma sugestão: identificar os principais “pain points” de processos de negócio e e desenhar projetos SOA para atacá-los. Ter em mente que os resultados a serem obtidos deverão ser rápidos e deixar bem claro as reduções de custo que serão obtidas. Onde conseguir budget para estes projetos? Basicamente existem três tipos de budget para projetos SOA:

a) Budgets específicos para SOA, que aparecem quando alguma tecnologia como ESB é necessária e seu custo não pode ser acoplado a nenhum projeto de negócio específico.

b) Budgets para os projetos de negócios oriundo das LOB (Line of Business) baseados em SOA. Tende a ser o mais comum.

c) Budgets redirecionados de outros projetos que não trazem valor agregado para o resultado do negócio e que podem ser postergados ou cancelados em tempos de retração econômica. Um exemplo? Nem pense em substituir XP por Vista nos desktops. Porque não trocar as licenças do Office por softwares gratuitos como Symphony ou OpenOffice?

A nossa conclusão, já na sobremesa, foi que o caminho para SOA é inevitável. A razão é simples: cada vez mais TI está se transformando em BT (Business Technology), fazendo parte do próprio negócio, contribuindo de forma decisiva para melhorar resultados da

45

companhia. Ora, sem SOA isto é praticamente impossivel. Como fazer a empresa ser flexível, responder com rpoidez às mudanças no contexto de negócios, criar redes de valor temporárias? Mas, por outro lado a pressão pelo curto prazo existe e não podemos ignorar o mundo real. Assim, buscando implementar projetos SOA de resultado rápido constrói-se, aos poucos, uma plataforma SOA. Mas, não esquecendo que esta plataforma precisa que os componentes sejam coerentes entre si. Ter uma estratégia SOA de longo prazo continua sendo fundamental. Apenas, em tempos bicudos, implemente “projetos rápidos” como uma forma de chegar lá.

46

Autor Cezar Taurion Gerente de Novas Tecnologias Aplicadas/Technical Evangelist da IBM Brasil, é um profissional e estudioso de Tecnologia da Informação desde fins da década de 70. Com educação formal diversificada, em Economia, Ciência da Computação e Marketing de Serviços, e experiência profissional moldada pela passagem em empresas de porte mundial, Taurion tem participado ativamente de casos reais das mais diversas características e complexidades tanto no Brasil como no exterior, sempre buscando compreender e avaliar os impactos das inovações tecnológicas nas organizações e em seus processos de negócio. Escreve constantemente sobre tecnologia da informação em publicações especializadas como Computerwold Brasil, Mundo Java e Linux Magazine, além de apresentar palestras em eventos e conferências de renome. É autor de cinco livros que abordam assuntos como Open Source/Software Livre, Grid Computing, Software Embarcado e Cloud Computing, editados pela Brasport (www.brasport.com.br). Cezar Taurion também mantém um dos blogs mais acessados da comunidade developerWorks (www.ibm.com/developerworks/blogs/page/ctaurion). Este blog, foi, inclusive o primeiro blog da developerWorks na América Latina. Para entrar em contato com o autor, use ctaurion@br.ibm.com ou ctaurion@gmail.com.