[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).
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: arquitetura, gerenciamento_de_projetos, soa
quarta-feira, 27 de julho de 2005 |
Assine o finito
Lista completa no del.icio.us
neste post
Qual é a sua opinião?