Publicidade

Gestão

Cinco maneiras de implementar SOA

Acompanhe casos de companhias como Comcast e United Airlines, que estão aderindo a SOA e mudando o modo de planejar, desenvolver e implementar aplicações empresariais.

Por IDG News Service

11 de novembro de 2007 - 21h50
página 1 de 5

Quando a arquitetura orientada a serviços (SOA) começou a ganhar força, a meta era simplesmente disponibilizar funcionalidades de aplicações como um serviço compartilhado. Ao longo do tempo, as empresas construíram suas arquiteturas -- e continuam construindo. A diferença é que, nos últimos dois anos, o lado do negócio adquiriu melhor percepção do valor estratégico de TI, enquanto TI aprendeu mais sobre as pressões competitivas que o negócio tem que suportar. Conseqüentemente, agora mais do que nunca, SOA propicia maior alinhamento entre TI e negócio.

O negócio precisa de um conjunto de serviços que possam ser recombinados, resultando em novos processos de negócio que suportam novos produtos ou serviços. SOA diz respeito a publicar estes serviços e fornecer um framework coerente dentro do qual eles possam ser governados e compostos em aplicações. Apesar de muitas iniciativas SOA continuarem em uma fase inicial, a promessa de maior compreensão do negócio é real. E estamos vendo um número crescente de empresas promovendo implementações avançadas. Os estudos de caso a seguir são ótimos exemplos.

Comcast constrói SOA sobre expertise em domínio
Quando você decide adotar a abordagem SOA, é tentador começar a comprar barramento de serviços empresariais (enterprise service bus --ESB), registros e outras ferramentas. Mas o valor principal de SOA é posto de lado: o alinhamento entre as aplicações que você cria e implementa e os processos de negócio que elas executam, ressalta Tom Adler, gerente sênior de arquitetura de aplicação e governança de TI da Comcast. Começar com a arquitetura pode ajudar você a garantir que tem o framework certo para fazer isso – agora e à medida que as necessidades mudam, com o correr do tempo, segundo Adler.

“Quando iniciamos esta empreitada, 18 meses atrás, resistimos à tentação de trazer fornecedores. Trouxemos especialistas em determinados assuntos e descobrimos do que precisávamos em primeiro lugar”, diz Adler. “Todos os fornecedores só queriam nos vender um ESB.”

Adler observa que a iniciativa de arquitetura vai além de estabelecer o framework: ela identifica onde você já tem redundâncias, tanto em processos de negócio quanto em aplicações. Isso é fundamental para conquistar a adesão do negócio porque mostra, em termos muito reais, não só onde há oportunidades de economia que vão ajudar a justificar o investimento em infra-estrutura e ferramentas SOA, mas também onde o uso de serviços comuns reduzirá as complexidades de manutenção e integração, possibilitando esforços de desenvolvimento mais responsivos no futuro. “É o target que nos permite eliminar serviços redundantes”, diz Adler.

Depois de desenvolver a arquitetura – que Adler chama de modelo de domínio comum – o próximo passo da Comcast foi desenvolver o framework de governança para a criação e a implementação de serviços. “Os serviços precisam passar pelo portão da governança”, explica, “ou ninguém vai saber que o serviço existe ou adotar as políticas e os procedimentos certos”. Somente os serviços que passam pelo portão da governança são acrescentados ao registro de serviços e, assim, disponibilizados para reutilização.

Um desafio da governança que despontou rapidamente foi decidir quem era o “proprietário” dos serviços. A Comcast é bastante descentralizada e, portanto, a cultura da empresa naturalmente suportava que os criadores do serviço possuíssem os serviços em seus domínios. Serviços comuns, como single sign on, residem em TI, seu domínio natural, diz Adler.

Adler agora percebe que a Comcast deveria ter desenvolvido um modelo de serviço de dados comum depois de definir a arquitetura. Sem serviços de dados padrões para acessar informação corporativa e gerenciar interações entre sistemas, os desenvolvedores acabaram projetando seus serviços para executar o trabalho de diferentes maneiras, o que gerou inconsistências, quebrando a promessa de SOA de possibilitar um mix fácil de componentes de serviços. “Subestimamos o valor no início”, admite Adler, e o preço disso foi, posteriormente, ter que refazer alguns serviços para impor este modelo.

Outros destaques do COMPUTERWORLD:
>TI depois das fusões: delicada relação
> Mais de 50% dos europeus pagaria mais por tecnologia 'verde'
> China investe pesado em tecnologia de gestão de risco
> Forrester: corporações continuam dizendo não ao Vista
> Seis práticas que mais fazem os CIOs perderem tempo

O foco arquitetural da iniciativa SOA da Comcast ajudou a aplicar o conceito mais amplamente do que se ele fosse visto apenas como uma questão tecnológica, acredita Adler. A Comcast não partiu da visão de que SOA significa usar web services e aplicou o conceito SOA a todos os seus esforços, não apenas aos que eram claramente capacitados para web. “Um web service é simplesmente mais uma maneira de expor um serviço – um detalhe de implementação”, diz.

Opinião do Leitor
Não há comentários para essa notícia
Publicidade
Publicidade
As mais lidas
60 melhores empresas de TI e Telecom para trabalhar

A elite do RH de TI e Telecom no Brasil

Computerworld e Instituto GPTW apresentam as Melhores Empresas de TI e Telecom para Trabalhar 2009.

Veja o Especial

Confira o ranking:

  1. Chemtech
  2. Kaizen
  3. Microsoft
  4. Cisco do Brasil
  5. Google Brasil
Veja o ranking completo com as 60 empresas

SLIDE SHOWS

Publicidade
coluna tv
Newsletters
Assine a Computerworld