[SOA # 3] - É o Negócio, Estúpido!

Um dos principais apelos e, porque não dizer, motivo de estranheza quando se analisa uma proposta de implementação de uma SOA, é o fato dela não apresentar ou forçar a utilização de nenhuma nova tecnologia. Pelo contrário. SOA deve promover a sobrevida dos ativos de software de uma organização, tanto das aplicações de negócio quanto dos elementos de infra-estrutura (como servidores de aplicações, middleware para comunicação assíncrona, dentre outros). Martin Frick chega a sugerir que troquemos o termo “sistema legado” por “Sistema Herdado” [3].

O fato é que há muito conhecimento codificado na forma de software e espalhado pelas organizações. Mesmo após a implementação de soluções de integração de larga escala como os ERPs e sistemas CRM, a arquitetura de software das empresas continuou fragmentada, com diversos silos de informação. A característica “monolítica” destas soluções tornou cada esforço de integração uma espécie de barreira para a implementação de mudanças e novas funcionalidades no nível do negócio.

O “ovo de Colombo” de uma proposta SOA está em seu linguajar, totalmente orientado ao Negócio. Os Serviços, suas Interfaces e Contratos são apresentados na língua de seus usuários e clientes. Elimina-se desta forma aquela distância e confusão que sempre caracterizou as interações das áreas de TI com seus usuários. Mas esta nova aproximação requer uma revisão na estrutura e processos da organização de TI, como será apresentada nos capítulos seguintes.

Não é objetivo deste artigo tratar de questões acerca dos aspectos tecnológicos de uma implementação de uma Arquitetura Orientada a Serviços. Mas é importante lembrar que o conceito SOA nasceu logo após o advento dos Web Services. Estes nasceram com escopo relativamente limitado, propondo uma forma de integração de aplicações utilizando padrões abertos da Internet. Apesar de não serem obrigatórios para a realização de uma SOA, os Web Services e os padrões que os viabilizaram, como XML (eXtensible Markup Language), SOAP (Simple Object Access Protocol) e WSDL (Web Service Definition Language), dentre outros, podem favorecer, e muito, a implantação de uma SOA. Mas deve-se lembrar que SOA não é um conjunto de Web Services e, por outro lado, o fato de uma empresa ter uma porção de serviços Web não significa necessariamente que ela possua uma arquitetura de aplicações orientada a serviços.

As organizações de TI têm, talvez pela primeira vez em sua história, a oportunidade de fazer com que seus investimentos e custos tenham claro e inequívoco objetivo de negócio atrelado. Mas o sucesso de uma implementação SOA depende de uma ampla e compartilhada visão de seus objetivos, restrições e roteiro de construção. Como será exposto nos capítulos seguintes, a gestão do Programa SOA e respectivos projetos desempenha papel fundamental nesta realização.


>>>>>>>>>> SOA #4 - O Programa SOA

3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
Prentice Hall (PTR) (2005).

Marcadores: , ,

quarta-feira, 27 de julho de 2005 | | Compartilhe: Adicionar esta notícia no Linkk

neste post

Qual é a sua opinião?

A T E N Ç Ã O

Esta é uma versão antiga do finito. Só é mantida aqui porque o Google ainda direciona algumas buscas para cá. E eu seria louco se simplesmente o desativasse, certo? Mas, por favor, não deixe de visitar o finito certo. Todo o conteúdo aqui disponível está lá também.
  • Catálogo de Serviços

  • Contato Imediato

    • My status

    Assine & Compartilhe

    Busca

    Technorati


  • Temas & Tags

  • Lista completa no del.icio.us
  • Últimos Posts

  • Créditos & Débitos