por Felipe Dreher | InformationWeek Brasil
em 13 de outubro de 2009

Em fevereiro de 2009, a rede Lojas Renner começou a migrar aplicações para cloud computing. “Temos algumas soluções já funcionando e outras em piloto”, revela Leandro Fachin Balbinot, diretor de TI da rede de varejo, listando como exemplo do que roda em nuvem a ferramenta de controle de projetos corporativos e alguns portais com para compartilhamento interno de informações.

A estratégia de computação em nuvem da companhia nasceu em novembro do ano anterior com a identificação da necessidade de criar um portal de colaboração. Os três meses seguintes foram dedicados à aprovação das iniciativas e definição da arquitetura a ser utilizada.

A avaliação do conceito considerou parâmetros que passaram por escalabilidade e flexibilidade da solução, custo por licença, velocidade de implantação e independência – uma vez que os usuários ganham certa autonomia para lidar com a tecnologia, liberando a equipe de TI para atividades mais necessárias. “A alternativa mais adaptável seria do Google”, revela Balbinot, dizendo que o projeto entrou em produção em junho, promovendo colaboração entre áreas da empresa através de canais formais e redes sociais.

Os sistemas do fornecedor rodam sobre uma camada de soluções de transações internas da corporação. “Isso permite criar fluxos de trabalho com pessoas de outras áreas da empresa, flexibilizando a automatização de processo”, conta. Aos poucos mais coisas vão para nuvem. De acordo com o executivo, e-mail, agenda e mensageria estão sendo migrados para o conceito.

O CIO revela que todo o trabalho foi conduzido de forma a garantir segurança ao acesso das informações. “Fizemos vários testes para ter certeza de que não teríamos problema”, conta, citando cuidados tomados para não colocar aplicações de missão crítica no modelo. “Todas as informações voláteis, que não precisam de armazenagem histórica ou analítica complexa, ficam na nuvem”, revela o executivo, mencionando a existência de uma conexão segura entre Google e rede interna para mover as ações de negócio. Essa conversa entre os sistemas tem como suporte um software de BPM da Oracle.

Balbinot aponta para um fato que precisa ser dimensionado e considerado na migração para cloud: a velocidade das aplicações são, geralmente, mais lentas do que os softwares que rodam dentro da empresa. Mesmo assim, o diretor menciona que o impacto do projeto na infraestrutura tecnológica das Lojas Renner foi “muito pequeno”, uma vez que o poder de processamento encontra-se nos data centers do Google.

“O que tivemos que colocar, nesse início de projeto, foi o planejamento de provisão de usuários para controle de acesso e a parte de conexão segura. Feito isso, é um trabalho muito mais de arquitetura de computacional normal para conectar o sistema de acordo com o que ele precisa”, reflete o executivo, sem mencionar quantas licenças foram adquiridas ou funcionários inseridos na aplicação.

Um dos pontos que facilitou a incursão pela nuvem da rede de varejo reside numa TI baseada em arquitetura orientada a serviços (SOA) o que, na visão do diretor, permite uma conexão capaz de viabilizar modelos tecnológicos híbridos.

O sucesso obtido na experiência até o momento faz com que as Lojas Renner planeje novas tecnologias rodando em cloud. “Tudo que não for estratégico ou crítico, olharemos para migrar num futuro próximo”, arrisca, salientando que aplicações de rotina tendem a ir mais rapidamente para a nuvem. “Pegar uma aplicação interna específica é mais delicado”, avalia o CIO, vislumbrando que as empresas que já possuem uma TI robusta montada partirão aos poucos para o modelo, enquanto empresas nascentes tendem a – em alguns casos – até descartar a hipótese de adquiriremparques próprios.

Fonte: CWConnect

Anne Thomas Manes escreveu um obituário para SOA, alegando que:

SOA encontrou seu falecimento em 1º de Janeiro de 2009, quando foi eliminado pelo impacto da recessão econômica. SOA é sobreviveu por sua descendência: mashups, BPM, SaaS, Cloud Computing e todas as outras abordagem de arquitetura que depende de “serviços”.

Ela continua:

Depois de ter sido considerada a salvadora da TI, SOA transformou-se em uma experiência fracassada — pelo menos para a maioria das empresas. SOA deveria reduzir custos e aumentar a agilidade em uma escala maciça. Salvo em situações raras, SOA falhou em entregar seus benefícios prometidos. Depois de investir milhões, sistemas de TI não são melhores do que antes. Em muitas empresas, as cosias estão piores: custos estão elevados, projetos demoram mais tempo e sistemas estão mais frágeis do que nunca. As pessoas que controlam as finanças já estão cansadas disso. Com o orçamento apertado de 2009, a maioria das empresas cortou fundos para suas iniciativas SOA.

Embora SOA tenha sido inicialmente adaptada principalmente por técnicos, sua base é mais negócios do que problemas técnicos. Mas eles foram introduzidos (e muitas vezes executados) pelos técnicos e vendedores, que estavam mais interessados nas tecnologias SOA (venda de software) do que no seu impacto sobre os negócios:

As pessoas esqueceram o objetivo do SOA. Eles estavam muito envolvidos em debates bobos de tecnologia (ex:, “qual é o melhor ESB?” ou “WS-* versus REST”) e eles esqueceram a coisa mais importante: arquitetura.

Uma incapacidade de mostrar um rápido ROI levando tomadores de decisões de negócio de várias empresas para longe do SOA:

A esteria do SOA transformou-se em desilusão SOA. Empresários deixaram de acreditar que SOA entregará benefícios espetaculares. “SOA” transformou-se em uma palavra má. Ela precisa ser retirada do nosso vocabulário.

Isso significa um enorme retrocesso da indústria de TI:

O fracasso do SOA é trágico para as indústrias de TI. As empresas necessitam desesperadamente fazer melhores arquiteturas para seus portfólios de aplicações. Orientação a Serviço é uma condição para integração rápida de dados e processos de negócios, isso permite a situação dos modelos de desenvolvimento, tais como mashups, e é fundador da arquitetura para SaaS e cloud computing.

Então o que vem agora? De acordo com Anne:

Embora o termo “SOA” esteja morto, a exigência da arquitetura orientada a serviços está mais forte do que nunca.

Sua sugestão é parar de falar sobre o SOA e começar a falar sobre serviços (embora ela não esteja clara sobre a sua definição deste termo, deixando assim margem para interpretação e interpretações erradas).

O post muito obviamente despertou reações entre alguns lideres nesta área.

David Linthicum analisou o que deu errado, para parafrasear:

• Falta de arquitetos qualificados que entendem SOA.
• Grandes empresas de consultoria focando mais em táticas e horas faturáveis do que resultados
• Os vendedores centralizaram demais na venda e não o bastante na solução.
• Anunciar que o SOA é uma panacéia para todos os males de TI

Joe McKendrick observa que o SOA é um estilo de arquitetura e não um produto:

Sucesso do SOA é parte de um processo transformador que muda a forma como as organizações são administradas e a forma de fazer negócios. Algumas organizações parecem só “entender isso” depois de um tempo. Para muitas empresas, no entanto, o que eles vêem como SOA é mais uma arquitetura JBOWS (Just a Bunch of Web Services). SOA é tecnologia e filosofia. A combinação de tecnologias e abordagens empregadas para trabalhar na direção que mudará SOA. Há alguns anos, web services foi visto como o caminho, ontem era o REST e web ou enterprise 2.0, agora é o cloud computing. A beleza do SOA é que ela foi concebida para ser independente das tecnologias ou protocolos subjacentes.

Miko Matsumura apóia a sugestão da Anne para alterar a terminologia, mas enfatiza o fato de que o conceito do SOA, especialmente a dimensão dos negócios do SOA certamente sobreviverá:

Eu acredito que utilizar o SOA como um termo certamente diminuirá, mas as estratégias de endereçar os problemas fundamentais terá de continuar evoluir para fora do “círculo” do SOA. Ao mesmo tempo em que SOA está morto, SOA também é inevitável – mas pode vir com um nome diferente. O DNA das grandes empresas exigirá interfaces para separar apropriadamente o “o que” dos requisitos do “como” da implementação e o padrão de design do SOA será o único que compreenderá a visão de longo prazo da plataforma enterprise, multienterprise e “cloud”. Qualquer termo como SOA tem de experimentar o hype cycle que vai desde a mística lingüística, implementação, experimentação e eventualmente um grau da esteria de nomenclatura. SOA tem particularmente uma grande agenda e portanto um monte de pessoas abraçaram isso na esperança de que o SOA poderia ser seu salvador. Sinceramente eu vejo o mesmo tipo de padrão no “cloud”, o que quer dizer que não é facilmente definido por um termo técnico, mas um conjunto de interesses políticos vinculados a um conjunto de idéias e realizações.

Ele também adverte contra mais de uma reação, que é tão comum na recente história da TI:

Temor sobre a economia deveria pegar um assento traseiro no projeto de se tornar a mudança que nós precisamos. A era da reação emocional knee-jerk pode esperar ser relegado para 2008 (ou talvez no primeiro semestre de 2009) e nós podemos caminhar juntos tanto para a re-visão quanto para reconstrução da nossa infra-estrutura. Para compreender a grande visão nós precisamos de cada uma e todas as pessoas tornem-se a mudança que precisamos.

Steve Jones interpreta a declaração da Anne como:

Fornecedores estão correndo do SOA como eles empurraram para você coisas suficientes e agora eles querem empurrar toda a sua descendência: mashups, BPM, SaaS, Cloud Computing… A realidade é que de fato são os serviços que mais importam nesta fase do que em qualquer outra. Isto não significa que SOA está morto, isso significa que a fúria do marketing do T-SOA tem avançado já que não ESBs e ferramentas Web Service não vendem mais. O que fica é o fato de que SOA, assim como seus serviços são o ponto de partida para SOA e não dessas tecnologias bonitas… Se você adotar uma nova tecnologia sem que tenha uma mentalidade de serviço então você criará um grau de desordem que fará aquela em que consultores e vendedores engordaram com EAI, parecer um problema trivial. Fazer Spaghetti dentro do seu firewall em grandes aplicações é uma coisa, fazê-lo através da internet e com milhares de pequenas aplicações é completamente uma escala diferente do problema.

Steve então elabora a definição do serviço, promovendo uma abordagem de “primeiro negócio” e definindo-os como uma funcionalidade que pode ser exposta para o uso de outros:

…você precisa identificar seus serviços, entender o valor do negócio que eles fornecem, entender o custo do modelo para entregar esse valor e decidir sobre a abordagem da tecnologia adequada.

Nick Gall, por outro lado, discorda com a forma com que Anne conduziu ("longa vida aos serviços"):

Isto é pensamento de serviços, como convencionalmente entendido, que levou a confusão em que nós nos encontramos: fragmentação causada pelas interfaces de entidade especifica (serviços). Eu diria em no entando "viva longa a web". Eu estou chocado que no post a Anne nem sequer menciona a web!

Ele cita como exemplo de sucesso o Google, Amazon, até mesmo o Salesforce e atribue a eles, a maior parte da alavancagem da arquitetura web, comunidade web e modelos de negócios web "Web-orientation é uma condição necessária para a rápida integração dos dados e processos de negócios, ele permite a modelos de desenvolvimento específicos para cada situação, tais como mashups e é a arquitetura fundadora do SaaS e cloud computing".

E finalmente em uma visão similar, uma explosão do passado de 2005 da previsão de Don Box, que embora não relacionado nesta discussão, parece sugerir o mesmo: O termo SOA será espancado até a morte e a industria de software investirá ou reciclará alguns termos iguais para substituí-lo. Certifique-se de checar o post original da Annes.

Parece óbvio que mudando o nome provavelmente não corrigirá os problemas atuais do SOA, mas pode-se argumentar que com uma reorientação na arquitetura e nos aspectos de negócio, SOA vá para a frente. O que você acha? SOA está morto ou vivo e saltitante?

Fonte: InfoQ

ITIL é um conjunto de boas práticas para gerenciar infraestrutura de TI. Bastante difundida no Brasil, a versão 3 já terá uma boa documentação em Português até o final deste ano de 2008 (veja este link do ITSMF Brasil).

O que isto tem a ver com arquitetura orientada a serviços (SOA)? Tudo. Serviços que podem estar geograficamente dispersos, requerem inevitavelmente, um cuidado e atenção maior do pessoal de suporte e segurança (firewall etc).

O cenário atual não é um conjunto controlado e conhecido de servidores, típico das aplicações monolíticas. Agora temos um ou mais barramentos de integração (ESBs), conectando sistemas legados (alguns em mainframes), com serviços dispersos, internamente e externamente em fornecedores/clientes ou datacenters em algum lugar do mundo (cloud computing!), enfim…

Esta nova realidade requer um gerenciamento mais eficaz da infraestrutura na qual estão hospedados estes serviços. Do contrário vamos ter um “caos” e, injustamente, SOA pode acabar como “culpada”.

Para evitar esta situação, mais do que nunca, a equipe de integração/arquitetura deve envolver o pessoal de suporte desde o início dos projetos.

É recomendado que o pessoal de infra, por sua vez, conheçam um pouco da idéia que está por trás dos “serviços dispessos em qualquer lugar do mundo” e saibam que existem boas práticas para lidar com esta nova realidade. ITIL é uma delas.

Se você tem interesse no assunto, recomendo fortemente a leitura deste artigo.

Fonte: SOA, Simples Assim!