1
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 2
orientação a 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/ 3
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. 4
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. 5
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 6
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. 7
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! 8
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! 9
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. 10
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 11
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! 12
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! 13
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 clienteservidor. 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. 14
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 TInegó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