SOA e seus conceitos iniciais

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

2

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 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.

14

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.

15

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.

16

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.

17

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.

18

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

19

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;

20

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.

21

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

22

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 .

23

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"! .

24

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!

25

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!

26

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

27

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.

28

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

29

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

30

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 .

31

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

32

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.

33

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

34

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

35

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.

36

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

37

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

38

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.”.

39

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/ .

40

2) Building SOA Solutions with SCA (4 partes),
http://www.ibm.com/developerworks/websphere/techjournal/0510_brent/0510_br
ent.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!

41

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

42

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.

43

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

44

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á.

45

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.

46

SOA e seus conceitos iniciais

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie SOA e seus conceitos iniciais

Ähnlich wie SOA e seus conceitos iniciais (20)

Mehr von Marcelo Sávio

Mehr von Marcelo Sávio (20)

SOA e seus conceitos iniciais