FACULDADE PITGORAS DE UBERLNDIA

Importncia da Governana para a Arquitetura Orientada a Servios (SOA)

KSSIA AFONSO SOARES Faculdade Pitgoras de Uberlndia Especializao em Desenvolvimento de Aplicativos Web Avenida dos Vinhedos, 1200 - Morada da Colina E-mail: kassiaafsoares@yahoo.com.br

MARCUS VALRIO BRUNELI, Msc (ORIENTADOR) Faculdade Pitgoras de Uberlndia Professor do curso de Desenvolvimento de Aplicativos Web Avenida dos Vinhedos, 1200 - Morada da Colina E-mail: mvqbruneli@hotmail.com

FACULDADE PITGORAS DE UBERLNDIA

Importncia da Governana para a Arquitetura Orientada a Servios (SOA)

Resumo Este artigo tem como objetivo realizar uma anlise da Arquitetura Orientada a Servios (SOA) e da Importncia da Governana para a Arquitetura Orientada a Servios (SOA), como um controle para a tomada de decises necessrias para implementar SOA com sucesso nas organizaes, tendo em vista que cada vez mais as organizaes buscam formas de mitigar riscos com o desenvolvimento de padres e processos e assim, aumentar o poder de deciso para compartilhar objetivos e metas. Este artigo explora a importncia da Governana para a Arquitetura Orientada a Servios (SOA) analisando as vantagens e desvantagens e os pontos crticos de sucesso para a implementao da Arquitetura Orientada a Servios (SOA) nas empresas.

Palavras-chave: Arquitetura Orientada a Servios (SOA), Integrao, Legado, Arquitetura de Sistemas, Informao, Governana, Sistemas de Informao.

FACULDADE PITGORAS DE UBERLNDIA

Abstract This article aims to undertake an analysis of Service Oriented Architecture (SOA) and the Importance of Governance for the Services Oriented Architecture (SOA) as a control to make decisions necessary to successfully implement SOA in organizations, given that more and more organizations seek ways to mitigate risks to the development of standards and processes and thus increase the power of decision to share goals and objectives. This article explores the importance of Governance for the Services Oriented Architecture (SOA) analyzing the advantages and disadvantages and the critical points for successful implementation of Service Oriented Architecture (SOA) in enterprises.

Keywords: Service Oriented Architecture (SOA), Integration, Legacy, System Architecture, Information Governance, Information Systems.

FACULDADE PITGORAS DE UBERLNDIA

1. Introduo
A tecnologia de informao tem avanado de forma rpida nas empresas. O aumento significativo de informaes, a mudana constante de processos, de servios, a alterao constante da infra-estrutura corporativa e a falta de controle sobre tudo isso, exigem que haja uma governana corporativa com foco nos objetivos estratgicos. A falta de uma Governana em SOA (Arquitetura Orientada a Servios), onde no existe uma metodologia de desenvolvimento especfica, sem controle do que est sendo produzido, alterado ou do ciclo de vida, poder impactar os servios e causar prejuzos organizao. A crescente necessidade de partilhar informaes pertencentes a diferentes segmentos de mercado e a utilizao sistemas heterogneos tem levado as empresas a buscarem SOA como uma forma de projetar e integrar servios de negcio e definir processos para que se adequem as suas necessidades estratgicas. A integrao de sistemas busca a automatizao de processos organizacionais. Dada a complexidade das tecnologias de informao e dos diferentes pontos de vista torna-se importante definir alguns conceitos para entendimento dos temas relacionados. Servio: Um servio uma funo ou funcionalidade que se encontra bem definida, que isolada e que no depende da situao ou estado de outros servios (SILVA, 2004). Processo: Na viso de Martins (2005) o processo de uma empresa formado por uma seqencia de tarefas as quais podem envolver pessoas, aplicaes e/ou documentos, tambm pode servir de base para estruturar e integrar SI (Sistemas de Informao), quando este informatizado e automatizado, possibilitando interligar vrias aplicaes informticas. Midlleware: O conceito de Middleware corresponde a uma arquitectura tecnolgica que concentra num software centralizado um conjunto de informao, procedimentos e aplicaes. Este permite interligar sistemas,

FACULDADE PITGORAS DE UBERLNDIA

disponibilizar informao, transportar dados entre sistemas e fornecer canais de comunicao entre diversas aplicaes informticas (MARTINS, 2005)

2.

Arquitetura Orientada a Servios (SOA)

SOA apresentado na viso de Braga (2007) descrito conforme abaixo: O alinhamento das regras de negcio da empresa possuem o foco em seus objetivos nicos. Braga (2007) afirma que o negcio de uma empresa deve ser pensado de forma integrada, devido aos avanos na arquitetura, o cdigo legado e as prprias limitaes tecnolgicas. Evitando o retrabalho, custo e tempo ao reescrever linhas de cdigo em sistemas que j estejam funcionando h anos, proporcionando integrao de sistemas novos com sistemas legados, ou mesmo integrando sistemas novos em Java com sistemas novos em .Net por exemplo. Para Braga (2007) a utilizao de SOA se torna uma forma para melhorar a integrao de servios de negcio. SOA um conceito de arquitetura, uma forma de pensar e de projetar integrao entre servios de negcio e tambm de definir processos. Na percepo de Braga (2007) um processo de negcio formado pela integrao entre vrios servios, onde cada servio pode ser uma parte de um sistema. SOA possui um barramento central denominado ESB, Enterprise Service Bus, tal barramento possui uma srie de conectores onde esses servios so plugados. Por meio de tais conectores que ocorre a comunicao com diferentes tecnologias que vo desde SOAP (Simple Object Access Protocol) para webservices, CORBA, RMI tecnologias legadas. A integrao entre servios utilizando a arquitetura SOA ocorre atravs do ESB pois os processos de negcio do cliente no conseguem ser reproduzidos de forma adequada por meio de servios isolados. de suma importncia haver uma orquestrao e controle entre eles onde em alguns casos somente fluxos de servios, em outros, regulamentos que devem ser aplicadas a cada servio, ou mesmo questes transacionais, controlando servios em N servidores e tecnologias diferentes.

FACULDADE PITGORAS DE UBERLNDIA

As constantes mudanas da tecnologia e a evoluo do mercado levaram as empresas a buscarem metodologias para auxlio em suas necessidades de negcio. Para Koch (2006) SOA uma arquitetura abrangente e uma estratgia de TI onde, a criao de aplicaes dentro de uma empresa, demanda por meio da arquitetura, que todos os programas sejam criados com uma metodologia de desenvolvimento de software especfica, denominada

programao orientada a servio. Conforme descrito em Solues | SOA (Arquitetura Orientada a Servios) (2009) vamos encontrar o seguinte esclarecimento: A Arquitetura Orientada a Servios uma anlise feita sobre a arquitetura da empresa que possibilita criar servios de negcio interoperveis que podem ser reutilizados e compartilhados entre aplicaes e empresas. SOA oferece s empresas a possibilidade de utilizar o potencial de TI para acelerar e tornar dinmico o seu negcio, eliminando desta forma as frustraes, por meio da estruturao de solues mais flexveis e prazos mais curtos de desenvolvimento e tambm evidencia os investimentos de TI sobre a economia de recursos, esforo e tempo devido reutilizao de componentes e da sua flexibilidade, demonstrando ao pessoal no-tcnico a viso sobre o papel da TI e seu valor para o negcio. As caractersticas da SOA destacadas por Foina (2011) so: estar fortemente ligada aos processos de negcio da organizao a que pertence, assim como a utilizar de padres tecnolgicos consolidados. Classifica tambm como elemento importante dessa arquitetura, o Servio. Assim definida, o Servio uma pea de programa que tem a capacidade de responder a uma requisio externa, regressando uma resposta de acordo com os dados transmitidos no momento em que foram ativados. Tal ativao e resposta ocorrem por meio da Internet, dessa forma o servio vem a ser denominado WebService. De acordo com Bombarda (2008) a definio de Arquitetura de servios corresponde a uma metodologia para desenvolvimento de software, na qual servios representam todos os ativos de softwares da empresa e tambm descreve como sendo um componente, uma parte de desenvolvimento

FACULDADE PITGORAS DE UBERLNDIA

de um software onde ao fazer a juno de todos os mdulos, teremos um software completo quela determinada funo para qual foi desenhado, produto final do escopo do projeto onde foi determinada a criao de um servio. Para Braga (2007) a maioria dos middlewares de integrao dos ESBs (Enterprise Service Bus) tais como produtos da IBM, Oracle, Sun, BEA, open source, etc. so implementados em Java, um dos motivos especificados se deve a necessidade de comunicao com uma grande quantidade de tecnologias distintas, pois, com a utilizao de linguagens proprietrias seria difcil, uma vez que estas no se integram com muitas coisas.

3. Elementos da Arquitetura Orientada a Servios (SOA)

3.1. Fundamentos de SOA

Segundo Sa n to s (2 0 07 ) SOA no uma arquitetura baseada exclusivamente em Web Services, mas os Web Services so a melhor maneira de alcanar os fundamentos de SOA, e provavelmente por isso que as implementaes so vistas atravs do uso de Web Services Santos (2007) menciona que a Arquitetura Orientada a Servios baseiase em disponibilizar os componentes como servios de software. Destaca que os oito fundamentos de uma Arquitetura Orientada a Servios a serem seguidos so: a Neutralidade, definida como a independncia de plataforma; fundamento Padronizado que consiste na utilizao de padres; Consumvel a permisso da descoberta da arquitetura orientada a servios e a automao do seu uso; Reusabilidade baseia-se em reuso do servio sem necessidade de cpia ou re-implementao de cdigo; Abstrao consiste no servio em si onde no se leva em considerao a forma como foi implementado; Publicado consiste em definir as funcionalidades por meio de uma interface do servio, com preciso; Formal baseado no contrato de uso formal que determina as obrigaes entre o fornecedor e o consumidor; Relevante o usurio reconhece as funcionalidades apresentadas como um servio importante, notvel, relevante.

FACULDADE PITGORAS DE UBERLNDIA

3.2. Princpios de design:

Santos (2007) afirma que aps a compreenso dos fundamentos, necessrio ter em mente o que base nesta proposta, a qual ser preciso desenhar. Isto pode ser realizado de vrias maneiras, porm alguns princpios de design devem ser seguidos: A abstrao est definida na garantia de que um servio independe de uma implementao especfica e/ou outros detalhes onde o consumidor do servio no necessita conhecer todas as implementaes individuais e as mudanas internas dos componentes so permitidas sem afetar os clientes. Disponibilizao interna para os times de desenvolvimento. Generalizao baseia-se na garantia da utilizao de um servio no maior nmero de cenrios possveis, inclusive aqueles no esperados, descartando a necessidade de construo de servio especfico para cada nova demanda, isso feito para separar dados e comportamentos comuns dos definidos para uma maior aplicabilidade e para a insero de maior nmero possvel de dados e comportamento em um nico servio. Conformidade com padres trata-se do que conveniente e auxilia na adaptabilidade, quando se leva em conta as condies de inrcia e longo tempo para mudanas. Isso feito com o intuito de: possuir maior compatibilidade entre provedores de servios e consumidores; possibilitar maior velocidade de adoo para os novos consumidores; habilitar

consumidores na capacidade de troca dinmica de fornecedores de servios. Granularidade refere-se ao propsito das funcionalidades oferecidas pelo servio. De acordo com o ambiente, a granularidade pode ser maior ou menor, no caso dos Web services, a granularidade ser menor, pois a finalidade reduzir o nmero de transmisses e aumentar a probabilidade da mensagem chegar e completar as transaes durante a existncia da conexo. Fornecer servios alternativos permite a reutilizao dos diferentes servios disponibilizados possibilitando uma maior ou menor granularidade com a utilizao de design patterns. Nesse mbito, diferentes web services podem ser compostos com a finalidade de oferecer novos servios.

FACULDADE PITGORAS DE UBERLNDIA

Seguindo os fundamentos e os princpios de design, as vantagens adquiridas podem ser observadas a seguir: 1. Melhora radical da comunicao com os negcios, favorecendo a convergncia entre os negcios e processos de IT; 2. Obter a separao do servio fornecido, dando-nos a base para o entendimento dos custos do ciclo de vida do servio e como ele usado nos negcios; e, finalmente, 3. Aquisio do conjunto principal de aplicaes corporativas pela reunio de servios de mltiplas fontes. No ser a regra e isso compreensvel, pois o mais apropriado adquiri-lo de um recurso externo. Como exemplo, temos os servios considerados commodities, como servios de autenticao, onde se pode utilizar um agente seguro externo (SANTOS, 2007).

3.3. Componentes de SOA:

Uma definio cedida por Prado (2010) compara a arquitetura SOA com uma banda sinfnica, devido a essa ser composta por diversos instrumentos e cada um desempenhando uma tarefa especfica. Cita o autor que seria difcil imaginar um WSDL (Web Service Description Language) que no possui XSDs (XML Schema Definition), uma ESB (Enterprise Service Bus) que no possui WSDLs e um BPEL que no possui SOAP (Simple Object Access Protocol), por serem vrios componentes sem ter sentido algum. Prado (2010) apresenta a seguir alguns conceitos sobre esses componentes de SOA: BAM (Business Activity Monitoring) De acordo com BAM Business Activity Monitoring: inteligncia de negcios em tempo-real (2009), uma caracterstica forte do BAM possibilidade de monitorar em tempo real as atividades de negcio. Permite um monitoramento onde possveis falhas esto propensas a ocorrer no processo de negcio. Tambm so fornecidas informaes e estatsticas tais como: quais processos de negcio esto em execuo e quais esto em pausa (PRADO, 2010).

FACULDADE PITGORAS DE UBERLNDIA

Segundo Inazawa (2009) as informaes do BAM so obtidas utilizando a implementao de sensores em locais estratgicos dos processos de negcio.

WSDL (Web Service Description Language) uma linguagem escrita em XML (eXtensible Markup Language) que descreve o Web Service como contrato dos servios, define tecnicamente como o local onde se obtm os parmetros de entrada, sada, tipos de dados, endereo do servio, dentre outros. (PRADO, 2010)

XML (eXtensible Markup Language) uma linguagem utilizada para facilitar a leitura e eliminao de erros por parte de humanos, padronizada pela W3C (Word Wide Web Consortium), empregada em descrio e troca de dados (PRADO, 2010).

XSD (XML Schema Definition) uma linguagem que descreve as regras de validao para um arquivo XML em tipos de dados bsicos e complexos (PRADO, 2010). Conforme descrito em XML Schema (2011), um arquivo contendo as definies na linguagem XML Schema chamado de XSD (XML Schema Definition), este descreve a estrutura de um documento XML.

SOAP (Simple Object Access Protocol) Segundo Holl (2010):

Simple Object Access Protocol consiste em um protocolo para troca de informaes estruturadas em uma plataforma descentralizada e distribuda utilizando tecnologias baseadas em XML. utilizado para invocar aplicaes remotas ou Web Services atravs de RPC (Chamadas Remotas de Procedimentos) ou troca de mensagens em ambiente independente de plataforma e linguagem de programao.

BPEL (Business Process Execution Language) Para Braga (2007) a arquitetura SOA utiliza-se do BPEL (Business Process Execution Language) para a modelagem dos processos de negcio,

FACULDADE PITGORAS DE UBERLNDIA

por meio deste possvel definir toda a orquestrao dos servios e regras do processo, sua linguagem baseada em XML.

UDDI (Universal Description Discovery and Integration) De acordo com Santos (2007) UDDI est definido como um padro de gerenciamento de Web services cujo objetivo registrar e localizar servios.

ESB (Enterprise Service Bus) A infra-estrutura (servidores) classificada como um dos componentes primordiais SOA por ser onde esto disponibilizados os servios. Tem como principal tarefa, prover conectividade, segurana, transformaes de dados e roteamento para que possa ser estabelecida a comunicao entre os sistemas por meio dos servios disponveis (PRADO, 2010).

4. Desempenho e Segurana

Para Lee (2009) os sistemas de TI possuem dois aspectos que normalmente quebram planos, conceitos e modelos: desempenho e segurana. Dependendo do ambiente, o desempenho em tempo de execuo um atributo crtico para o negcio. Problemas de segurana podem ocorrer na integrao de sistemas distribudos. Segue abaixo os detalhes de desempenho e segurana em SOA.

4.1. SOA e Desempenho

O desempenho dos servios segundo Lee (2009), leva em considerao os fatores que mais impactam, tais como: A impossibilidade de envio de dados binrios entre sistemas heterogneos, baseado na exigncia de SOA com relao ao mapeamento dos formatos em um formato comum, tal como o que se baseia em XML como o caso do SOAP para uma infra-estrutura de Web Services. Pode ocorrer aumento de tamanho em 4 a 20 vezes dos dados originais inclusive campos binrios quando representados em formato baseado em XML, causando

FACULDADE PITGORAS DE UBERLNDIA

elevao acentuada no consumo de banda de rede e/ou no tempo total de transmisso das informaes; As converses de formato e mapeamentos adicionais demandam tempo e necessitam ser realizadas pelo consumidor e fornecedor devido comunicao entre ambos; O desempenho das retransmisses causadas pelos extravios ou demora de entrega de mensagens, so impactados devido a redes e protocolos no confiveis. A reusabilidade favorecida pela granularidade grossa, porm pode resultar em quantidade excessiva de dados dispensveis trafegando

desnecessariamente pela rede, tornando-se de suma importncia afinar-se, continuamente a granularidade para atender as necessidades particulares de cada consumidor devido crescente oferta de servios customizados. Uma vez que os atributos no funcionais so elementos de um contrato de servio, SLA (Service Level Agreement), eles permitem forte influncia na criao de novos servios e na modelagem dos sistemas subjacentes. As modificaes em servios, citando como exemplo a adio de novos parmetros, podem gerar incompatibilidade entre verses j existentes caso o custo adicional de tempo de execuo exceda ao determinado pelo seu respectivo SLA (Service Level Agreement). 4.2. SOA e Segurana

Conforme Lee (2009) os principais aspectos de segurana so:

Autenticao: refere-se verificao da identidade de um usurio, um dispositivo fsico ou um requisitante de servio externo. Autorizao: determina o que uma identidade tem permisso de fazer. Confidencialidade: assegura que apenas aquele que chamou o servio possa ver os dados enquanto esto sendo transferidos entre o fornecedor e o consumidor. Integridade: impede que dados sejam manipulados ou falsificados de forma que se tornem incorretos. Disponibilidade: evita que os servios se tornem inoperantes por meio de contramedidas a ataques tais como os de negao de servio (DoS Denial of Service).

FACULDADE PITGORAS DE UBERLNDIA

Contabilizao: significa monitorar as chamadas de servio para gerenciamento, planejamento e outros propsitos. Auditoria: registro de informaes relevantes segurana, para permitir deteco e anlise de falhas de segurana e ataques. Envolve tambm registro de informaes legais quando for o caso. A melhor maneira de lidar com segurana em SOA fornecla como um servio: SES (Security Enforcement Services; servio de reforo de segurana) que de dentro de um ESB ou de um aplicativo chamam um SDS. SDS (Security Decision Service; servio de deciso de segurana).

5.

Conceitos de governana

Carvalho (2007) define este conceito de governana de forma abrangente, atribuindo os papis e as responsabilidades conforme abaixo:
Governana de TI um conjunto de prticas, padres e relacionamentos estruturados, assumidos por executivos, gestores, tcnicos e usurios de TI de uma organizao, com a finalidade de garantir controles efetivos, ampliar os processos de segurana, minimizar os riscos, ampliar o desempenho, otimizar a aplicao de recursos, reduzir os custos, suportar as melhores decises e conseqentemente alinhar TI aos negcios.

Carvalho (2007) conceitua que para obter uma Governana de TI efetiva preciso o desenvolvimento de um modelo organizacional especfico, utilizando as melhores prticas tais como: o BSC (Balanced Scorecard), PMBok (Project Management Body of Knowledge), Cobit (Control Objectives for Information and related Technology), ITIL (Information Technology

Infrastructure Library), CMMI (Capability Maturity Model Integration ) e ISO 17.799 extraindo os pontos que atinjam os objetivos do programa de Governana, e tambm considerando os aspectos culturais e estruturais da empresa, em decorrncia mudana dos paradigmas existentes. Em Solues | SOA (Arquitetura Orientada a Servios) (2009) vamos encontrar o seguinte esclarecimento: A Governana de TI propicia o alinhamento do setor de tecnologia com os objetivos da empresa de forma geral, definindo direitos de tomada de deciso, polticas, prticas, processos e maneiras de medir prioridades.

FACULDADE PITGORAS DE UBERLNDIA

Proporciona auxlio nestas reas, a compreender onde encontrar e como monitorar cada ativo da empresa. A Governana SOA vai mais alm. A Governana SOA um subconjunto da Governana de TI, o seu foco est voltado para o desenvolvimento e integrao de aplicaes, seu estilo de arquitetura corporativa isola funcionalidades de TI em servios orientados a negcios, oferece visibilidade e controle, e simultaneamente aumenta a agilidade que as reas de negcio exigem. A Governana SOA uma questo crtica, uma vez que essa plataforma promete unificar sistemas que envolvam diversos departamentos da empresa. A soluo para essa governana justamente compartilhar objetivos e metas.

5.1. Benefcios da governana:

Manes (2010) conceitua que: Governana eficaz um elemento crtico na promoo de uma iniciativa SOA bem sucedida. Governana de SOA ajuda a organizao a ter sucesso com SOA ao mitigar estes riscos atravs de regras estabelecidas, processos e poder de deciso. Um programa de governana SOA ajuda as pessoas a agirem de acordo com os objetivos da organizao e seguir as melhores prticas (MANES, 2010). A governana SOA, de acordo com o autor, fixa normas departamentais ou padres corporativos para auxiliar na garantia de que o servio de sistemas orientados obtenha resultados de valor almejado. A aplicao efetiva dos princpios SOA proporciona s organizaes alcanar os benefcios prometidos pela SOA. Padres de governana garantem que os designers e

desenvolvedores apliquem os princpios orientados ao servio e os padres de sistemas durante sua execuo. A governana SOA garante maior exatido de sistemas orientados a servios. O sistema que apresenta seu desenho consistente proporciona maior probabilidade de trazer os benefcios abaixo: Interoperabilidade: Sistemas distintos tm fcil interoperabilidade quando ocorre a utilizao de padres de desenvolvimento, os quais garantem os servios de suporte a protocolos comuns e modelos de dados

FACULDADE PITGORAS DE UBERLNDIA

Componibilidade: um conjunto de normas e procedimentos de desenvolvimento que os desenvolvedores precisam seguir para garantir que os princpios de design comprovados e padres, permitam a composio e reutilizao de servios. Manutenibilidade: um conjunto de normas e procedimentos de desenvolvimento de princpios de design comprovado e padres que garantam sua utilizao pelos desenvolvedores que visa reduzir dependncias entre componentes do sistema, proporcionando fcil manuteno de componentes individuais. Visibilidade: Os padres de desenvolvimento garantem que os sistemas sejam adequadamente instrumentados, permitindo assim aos analistas de negcio monitorar os processos de negcio, e os analistas de sistemas monitorarem operaes em tempo de execuo para que eles possam detectar anomalias tcnicas e de negcios antes de se tornarem incidentes ou problemas. Tempo mais rpido ao mercado: A organizao ter capacidade de fornecer novas solues e melhorias mais rapidamente, devido ao crescimento do registro de servios interoperveis, de composio e de fcil manuteno. Retorno sobre o investimento (ROI): Os padres de design,

desenvolvimento e implantao asseguram que as organizaes tenham maior possibilidade de retorno sobre os investimentos aplicados.

5.2.

Princpios da Governana

Segundo Gerrard (2008): Os princpios da governana definiro o papel da TI de acordo com a estratgia de negcios da empresa, com o objetivo de oferecer suporte para garantir um gerenciamento de sucesso. s organizaes que possuem vrios setores de negcios tornam-se importante identificar as necessidades de suporte estratgico para cada unidade de negcios e desenvolver princpios baseados em servio compartilhado ou individualmente de forma a orientar como a TI ir suport-los. Os princpios da governana em TI afetam o papel da organizao:

FACULDADE PITGORAS DE UBERLNDIA

Na globalizao do negcio Na criao e reforo de prticas correntes de negcios Na otimizao do desempenho de processos de negcios crticos Na gesto do conhecimento e do capital intelectual dentro da empresa Na conformidade legal e regulatria (Sarbanes-Oxley etc.) (GERRARD, 2008).

5.3. reas de Governana

Segundo Gerrard (2008): Consiste na tarefa de identificar reas que demandem polticas e processos de governana de TI e estabelecer metas especficas para cada rea. Os instrumentos de medio so importantes para quantificar os resultados dos objetivos alcanados, por essa razo, devem ser includos s metas. As reas de governana em TI podem ser agrupadas em duas categorias principais:

A categoria rea de servios encara a TI como uma rea que presta servios. Assim como toda prestadora de servio deve ser levado em conta: a arquitetura de TI, os padres de desenvolvimento, as polticas de fornecedores, a centralizao ou descentralizao dos recursos e da gesto de TI. s Polticas de propriedade e uso de dados e processos deve ser levada em considerao a poltica de segurana e a poltica de continuidade de negcios. Para a categoria rea de demanda que est diretamente ligada aos processos decisrios, faz-se necessrio considerar: o alinhamento e a integrao do negcio e do planejamento de TI; a quantidade de recursos financeiros em sua totalidade dentre outros recursos deliberados a TI em uma empresa; a alocao de gastos e recursos de TI nos setores de negcios; os critrios destinados a avaliao do valor dos investimentos propostos aos projetos de TI em questo; a constatao dos benefcios dos projetos e novas provises do investimento em TI juntamente com as polticas de repasse de custos. Para Gerrard (2008) a plena aceitao da gerncia de negcios um pr-requisito primordial para o desenvolvimento dos princpios e reas de

FACULDADE PITGORAS DE UBERLNDIA

governana. Torna-se importante identificar as reas com mau funcionamento e construir um business case para mudar a governana de TI de forma eficiente na empresa. Este autor destaca que se possvel, preciso manter envolvimento direto dos gerentes de negcios com os membros de um conselho estratgico, supervisionando e dando direo estratgica para garantia de proteo e suporte necessrios para o bom desempenho do projeto.

5.3.1. As principais reas de governana

De acordo com Mitra (2005) seguem destacadas abaixo as principais reas de governana: Alinhamento estratgico baseia-se em alinhar os negcios de viso objetivos e necessidades com os esforos de TI. Entrega de valor fundamenta-se em como o valor da TI pode ser obtido por meio de resultados, tais como a rentabilidade, reduo de despesas, reduo de erros, a imagem da empresa melhorada, branding (marca), dentre outros. Gesto de riscos est apoiada em dar sequncia nos negcios e medidas que precisam ser tomadas para proteger os ativos de TI. Gesto de recursos fundamenta-se em potencializar os servios de infra-estrutura que constituem o ambiente operacional sob demanda (ODOE) ou outro ambiente de apoio a servios de aplicativos. Gesto de desempenho possui foco principal na superviso dos servios que so executados no ambiente operacional sob demanda, em uma empresa ou outro ambiente.

5.4. Processos de Governana

De acordo com Gerrard (2008) o desenvolvimento de um processo completo e prtico para alcanar metas a rea mais problemtica da implementao, pois se torna necessrio definir como ser alcanada a

FACULDADE PITGORAS DE UBERLNDIA

governana, levando-se em considerao a realidade da empresa e sua cultura de gerenciamento. preciso esclarecer:

Quando um indivduo deve ser solicitado a tomar uma deciso.

Quando a tomada de deciso deve ser compartilhada e o tipo de frum mais efetivo para colaborao. O tipo de informao necessria para a tomada de deciso Quais fruns consultivos devem dar informaes para quem toma a deciso. As atividades e responsabilidades dos membros da equipe. Quais atividades de suporte sero necessrias para fazer o processo funcionar. Os produtos finais que sero entregues.

Aps a definio dessas trs grandes reas, a implementao do projeto poder iniciar. A identificao das sobreposies de processos pode ser solucionada ponto a ponto a cada nova etapa. O planejamento e o acompanhamento do projeto podem ser obtidos por meio de um fluxo de trabalho (GERRARD, 2008). O PMO (Project Management Office) oferece desenvolvimento e suporte ao processo de governana de TI, atribuindo ao CIO (Chief Information Officer) e coordenando os processos e os envolvidos, propiciando o alinhamento entre as atividades de TI e os negcios (GERRARD, 2008).

5.5. Os fracassos da governana e os motivos que as levaram.

O fracasso da implementao conforme Gerrard (2008), normalmente resultado de um ou mais dos trs fatores a seguir:

5.5.1. Participao inadequada no gerenciamento do negcio

importante que a rea de negcios tenha participao ativa no processo e que de acordo com a situao assuma responsabilidade direta. Os executivos de TI devem elaborar uma justificativa forte para o investimento no projeto de governana, demonstrando o valor que ser agregado ao negcio da empresa. Caso isso no ocorra, a governana de TI ser considerada como se fosse uma atividade de TI, no obtendo prioridade por parte da empresa e o

FACULDADE PITGORAS DE UBERLNDIA

suporte necessrio para alinhar o projeto de governana rapidez na tomada de deciso nos negcios. Os CIOs e os gerentes de negcio so responsveis por implementar a governana.

5.5.2. Ausncia de metas claramente articuladas

O autor afirma que a ausncia de uma definio clara das metas a serem alcanadas poder gerar dvidas sobre o envolvimento por parte de determinados participantes no processo de governana de TI, a importncia de sua participao no processo de governana se no for bem esclarecido poder no contribuir de maneira significativa na utilizao da governana como uma ferramenta para atingir as metas de negcios.

5.5.3. Falta de processos claramente definidos

importante que um processo prtico e claramente definido seja criado para alcanar as metas estabelecidas para a governana. Esse processo deve identificar o estilo de tomada de deciso, a cultura e as prticas da empresa, alm de estabelecer etapas de ao, papis dos envolvidos, responsabilidades e produtos finais e intermedirios a ser entregues. Embora a governana possa ser a forma de incluir somente a atribuio de direitos de deciso e responsabilidades finais pertinentes, na prtica ela deveria considerar uma diversidade de responsabilidades que atualmente so vistas de forma superficial, como critrios de controle e deciso, atividades de gerenciamento e atribuies de direitos de deciso. Os gerentes de TI que se propem a desenvolver um processo de governana mais efetivo deveriam comear por considerar a governana de TI como um conjunto de processos individuais para atingir metas individuais (GERRARD, 2008).

5.6. O ciclo de vida da governana SOA

Como caracteriza Schepers e Kratz (2009), a governana SOA est relacionada a iniciativas que possuem o objetivo de aumentar a qualidade total de SOA para controle de ambientes complexos. Segue abaixo suas relaes: Pessoas: para garantir que as responsabilidades esto sendo

distribudas acertadamente e que as pessoas esto recebendo o suporte necessrio para aquisio de conhecimento e habilidades devidas.

FACULDADE PITGORAS DE UBERLNDIA

Processos: para definir a aplicao correta de processos visando garantir qualidade e monitoramento dos servios. Produtos: so importantes para cadastrar os requisitos dos servios e tambm sua documentao com os devidos templates. Esses tpicos esto relacionados a um modelo do ciclo de vida de governana SOA onde define seis principais processos para obter uma boa governana SOA. O ciclo de vida representa a forma como projeto interage com o escopo para implementar uma arquitetura orientada a servios conforme o desejado. Atravs das vrias iteraes do ciclo de vida de governana SOA que ocorre o desenvolvimento de SOA com tendncia do aumento da maturidade. A viso SOA e o impacto organizacional trabalhado por meio das pessoas e dos processos para manter foco no negcio. Os trs processos de gerenciamento do portflio de servios, gerenciamento do ciclo de vida dos servios e o gerenciamento do nvel dos servios formam o foco dos arquitetos. O processo do gerenciamento do nvel de servios de

responsabilidade do administrador do sistema. Porm todas as partes que atuam na governana SOA devem estar comprometidas em todo o ciclo de vida.

5.6.1. A viso SOA

A iterao possui como primeiro passo definir os objetivos SOA a longo prazo ou revisar os objetivos j existentes. O alinhamento entre as reas de negcio e Ti ocorre por responsabilidade dos arquitetos para obter a viso SOA (SCHEPERS e KRATZ, 2009).

5.6.2. Criando a organizao SOA

Durante

este

processo

ocorre

determinao

dos

papis

responsabilidades da governana SOA. O comit composto pelos responsveis pela governana tais como analistas de negcios e profissionais de TI, pode

FACULDADE PITGORAS DE UBERLNDIA

surgir, para decidir como poder ser implementado o ciclo de vida de governana SOA e auxiliar para que os princpios SOA e os seus devidos padres sejam implantados dentro da organizao. A iterao corrente do ciclo de vida necessita das pessoas adequadas no lugar certo para sua execuo (SCHEPERS e KRATZ, 2009).

5.6.3. Gerenciamento do portflio de servios

Nessa etapa do processo importante a obteno do consenso juntamente com os representantes de negcio sobre quais sero os servios desenvolvidos. O arquiteto deve mostrar quais so os servios candidatos a reutilizao, no gerenciamento do portflio de servios e envi-los para serem desenvolvidos primeiro. O portflio de servios visa um roteiro listando os servios atuais e os planejados (SCHEPERS e KRATZ, 2009).

5.6.4. Gerenciamento do ciclo de vida de servios

Esse processo visa implementar, atualizar e retirar servios da corporao. O gerenciamento do ciclo de vida necessita ser conduzido pelo comit de governana SOA, que o responsvel por gerenciar as mudanas no ambiente SOA. A reutilizao de servios e execuo de regras de negcio por toda a empresa faz parte das mudanas. No comit de governana SOA o papel dos arquitetos destina-se na garantia de que todos os servios sejam direcionados ao ciclo de vida de gerenciamento para que no haja servios no-gerenciados (SCHEPERS e KRATZ, 2009).

5.6.5. Execuo dos princpios

O foco desse processo so os princpios de design e execuo. Como parte desses princpios o arquiteto deve garantir que as pessoas disponibilizem seus servios em um repositrio para gerenciamento e reutilizao onde os princpios devem ser aplicados em tempo de design. Os padres para desenvolvimento de servios denominam-se princpios em tempo de design e

FACULDADE PITGORAS DE UBERLNDIA

normalmente so adotados como modelos de melhores prticas, no podem ser monitorados automaticamente, dessa forma os desenvolvedores devem estar cientes de que eles precisam seguir os padres. Os arquitetos durante a entrega dos novos servios para a organizao devem verificar se as definies foram adotadas corretamente, por meio de uma reviso

(SCHEPERS e KRATZ, 2009).

5.6.6. Gerenciamento do Nvel de Servios

Ao comparar SOA com diferentes aplicaes observa-se a necessidade de um gerenciamento diferente de outras arquiteturas de TI, em conseqncia granularidade dos seus servios. Os consumidores precisam entender o nvel de granularidade dos servios para terem capacidade de adaptao em relao ao seu consumo. O administrador de sistema o responsvel pela atividade de Gerenciamento do nvel de servios, mas o cuidado com a sua granularidade ficam a cargo dos arquitetos para que possam argumentar com a equipe de negcio sobre a existncia de determinado nvel que seja til para os usurios do negcio. Ao revisar a utilizao dos servios talvez com uma ferramenta de registry, possibilite o surgimento de reutilizao (SCHEPERS e KRATZ, 2009).

5.7.

Os cuidados

Conforme Braga (2007) ao pensar nos processos de negcio de uma empresa como um todo, de forma a integrar sistemas, utilizando arquivos de texto ou Webservices, podem trazer por meio desses mtodos dois problemas que so: - Dependncia 2 a 2 entre sistemas, onde um sistema depende diretamente de outro, e assim sucessivamente, apresentando dessa forma malhas infinitas de dependncias de sistemas. - Falta de integrao, controle e regras nos servios disponibilizados por cada sistema. Um servio neste cenrio uma parte de um sistema que est sendo compartilhada para reutilizao.

FACULDADE PITGORAS DE UBERLNDIA

De acordo com Fusco (2007), de suma importncia a avaliao dos passos errneos que podem caminhar rumo ao fracasso, quando se trata do processo que analisa quais as etapas conduzem a um projeto de SOA bem sucedido. Para tanto preciso conhecer trs perfis, tambm classificados como perfis incorretos de projetos, os quais so construdos com apoio de fornecedores, analistas e clientes, segue abaixo as definies: A categoria denominada apressado apresenta projeto sem anlises de viabilidade, com falta de planejamento para as metas da empresa, apresenta desorganizao na implantao de tecnologias e servios, com tendncia ao desperdcio financeiro de milhes de reais. Como evitar: planejamento a palavra de ordem, por meio da anlise de onde a plataforma de aplicaes est hoje e quais os cenrios desejados. A caracterstica destacada para o perfil cauteloso est em se atingir o estado da arte, que consiste no excesso de conservadorismo, levando o gestor a perder uma boa oportunidade por adiar demais um projeto na esperana de conquistar o auge. Como evitar: comear a implementao em divises menores ou com projetos-piloto uma forma de testar SOA na prtica. Assim, pode-se evitar o adiamento excessivo. Afinal, fruta que amadurece demais, cai do p. Para o perfil apresentado como O transformador que possui conhecimento inadequado, 'imprescindvel entender que SOA no um produto, muitos gestores enganam-se ao acreditar que a compra de vrios sistemas os faro obter uma infra-estrutura em arquitetura orientada a servios, mas trata-se de uma contradio, pois SOA prioriza o reuso. Como evitar: cuidado com as ofertas e lembre-se de que o planejamento cauteloso (no demais!) auxilia na deciso do que essencial para suportar SOA.

5.8. A importncia da governana de TI e SOA

Como descrito por Mitra (2005): A TI um dos principais ativos dentro da empresa que precisa ser completamente compreendido para que os benefcios alcanados por seu

FACULDADE PITGORAS DE UBERLNDIA

intermdio sejam maximizados e geridos adequadamente de maneira que os seus riscos possam ser reduzidos. Para o autor SOA destaca-se como uma maneira de alinhar as estratgias de negcio e as urgncias de uma empresa com as atividades de TI. A natureza distribuda de servios atravs de vrias linhas de negcio faz com que uma empresa que adote SOA trate a governana com mais seriedade. Na percepo de Mitra (2005) a governana torna-se mais difcil devido ao aumento das peas mveis, ou seja, blocos de construo em forma de servios que precisam ser mantidos por diferentes organizaes, tanto dentro da empresa como fora dela. A organizao interna de servios. Os tipos de servios empresariais e sua capacidade de composio dentro dos limites organizacionais podem funcionar de forma adequada e eficiente se e somente se os servios forem comandados cumprindo as exigncias especificadas por um acordo de nvel de servio (SLA) tendo como fatores a segurana, confiabilidade, desempenho dentre outros. A governana SOA necessria para supervisionar o ciclo de vida do portflio de uma empresa de servios durante a identificao, especificao e criao para a implantao de servios da empresa. De acordo com o referido autor, o rastro de vrios desastres ocorridos no mundo corporativo levou empresas que utilizam padres de governana elevados, como Sarbanes Oxley (SOX) e de TI, com boas e eficientes prticas, a obter investidores dispostos a colocar seu dinheiro em suas empresas. Manes (2010) alega que a Governana o mtodo organizacional utilizado por uma sociedade ou organizao para se governar, esse sistema de meta-deciso auxilia, tal como uma organizao toma decises sobre a tomada de decises. Dentro deste contexto, a governana apresenta restries: Decises limitadas; estabelecimento sobre quem tem responsabilidade e autoridade para tomar decises; fixar parmetros e restries que controle, oriente, ou influencie nas decises; estabelecimento das conseqncias pelo no cumprimento.

FACULDADE PITGORAS DE UBERLNDIA

5.9. As boas prticas

Segundo Fusco (2007): Alguns conceitos bsicos podem ajudar na garantia de um projeto bem sucedido em SOA. O perfil a ser seguido refere-se a um planejamento bem estruturado, mapeamento de processos e doses certas de relacionamento para adquirir conhecimento com as experincias do mercado, esses fatores se bem equilibrados auxiliaro a no repetir os mesmos erros. Dicas relevantes cedidas pela autora, que consistem em: mapear e entender os sistemas e processos de negcios; ver onde a empresa pretende chegar; desenvolver o planejamento de SOA; priorizar o que necessrio no curto, mdio e longo prazo pelas reas que patrocinam o negcio; conduzir a implementao em etapas; e cuidar para que tudo isso seja gerenciado com avaliaes peridicas de maneira a evitar erros posteriores.

5.10. Como estruturar uma rea de governana.

De acordo com Gerrard (2008): Atualmente a governana de TI constituda por estrutura, princpios e processos. Segundo a abordagem da implementao, os princpios devem ser definidos primeiramente. Logo aps o desenvolvimento e os processos devem ser empregados para especificar os passos, papis desempenhados e responsabilidades. Na viso de Leaver (2010) os departamentos de uma empresa devem trabalhar focados em um mesmo objetivo de forma a alcanar os resultados almejados.

5.10.1. A estrutura da governana da amostra organizacional

Na opinio de Mitra (2005) uma estrutura de subordinao hierrquica organizacional deve apoiar a implementao de governana. Segue evidncia de quatro categorias de hierarquia:

FACULDADE PITGORAS DE UBERLNDIA

Nvel de patrocnio: composto pelas partes interessadas no comit de direo e sua representao determinada pelos membros do c-suite que um grupo composto por chefe executivo, diretor financeiro, diretor de informtica dentre outros, em conjunto com os proprietrios e executivos de LOB que so as linhas de negcio. O comit de direo publica a estratgia de negcio, objetivo e viso para a empresa. Os membros do comit so os mais importantes tomadores de deciso a respeito de como a escolha deve ser feita para o investimento em TI e canalizados para as reas especficas do negcio que no necessitam de melhoria de processos de negcio ou sobre a necessidade de desenvolver novas aplicaes competitivas de mercado. Nvel de liderana: constituem este nvel, o lder(s) de governana do centro de excelncia (COE) e dois representantes, sendo um de negcio e um de TI para cada domnio do negcio, ou seja, servios empresariais agrupados logicamente que dividem um contexto de negcios comum. Os princpios corporativos de TI e a arquitetura SOA so desenvolvidos pela equipe de liderana, e so regras mais abrangentes a que devem ser cumpridas por qualquer arquitetura de aplicativo. A arquitetura do aplicativo que precisa ser implementado uma prioridade que deve ser obdecida, pois ela garante que as necessidades de TI estejam alinhadas com as de negcio. A equipe de liderana representa o rgo de administrao, que faz a documentao dos padres de arquitetura, dos requisitos de conformidade aos atos regulamentares, das restries de arquitetura corporativa. A equipe possui poderes de fiscalizao da conformidade global com os padres de arquitetura, diretrizes, princpios e restries assim que for necessrio conceber e implementar qualquer nova aplicao pelas equipes seguintes. Nvel de gesto de oportunidades: Neste nvel necessria a formao de equipes separadas, onde o foco de cada uma est direcionado para as necessidades do negcio no valor de uma ou mais, e, tambm possuem a responsabilidade em alcanar definies claras de aplicativos de negcios que atendam a uma necessidade especfica da empresa. Cada

FACULDADE PITGORAS DE UBERLNDIA

equipe de iniciativa deve possuir um lder de equipe comercial que possui a responsabilidade de recolher e formalizar os requisitos de negcio. Nvel de gesto de Projeto: As equipes que se encontram neste nvel so responsveis por gerenciar o ciclo de vida inteiro do projeto de aplicao especfica e por desenvolver ao longo das fases de definio da soluo, o esboo da estrutura de tpicos de soluo, macro design, micro design, construo, teste e implantao. O alinhamento obtido por cada equipe do projeto com uma determinada equipe de iniciativa. A execuo de vrios projetos simultneos ocorre de forma comum em uma determinada equipe de iniciativa. A hierarquia e a estrutura organizacional so essenciais para a governana na empresa de hoje. As empresas possuem uma variao elevada em sua estrutura organizacional e cultural, o que torna inevitvel a personalizao estrutura. da

6.

Consideraes finais

Devido modernizao, as pessoas e as empresas se vem influenciadas a se manterem atualizadas para atender demanda

mercadolgica existentes. As organizaes preocupam-se com o custobenefcio por isso buscam equipamentos que iro representar um investimento respeitvel e consciente para acompanhar a evoluo do mercado tecnolgico. As tecnologias de informao, por meio da utilizao de suas ferramentas, ajudam os gestores na tomada de decises, para obter vantagem estratgica sobre os seus concorrentes. A aplicao dos princpios SOA muito importante para que as organizaes possam alcanar suas metas atravs dos benefcios prometidos pela SOA. Os padres corporativos fixados pela Governana SOA, ajudam a garantir que os resultados de valor sejam atingidos e tambm auxiliam a obter maior exatido de sistemas orientados a servios.

FACULDADE PITGORAS DE UBERLNDIA

A governana SOA est relacionada s pessoas, processos e produtos os quais possuem o objetivo de aumentar a qualidade total de SOA para controle de ambientes complexos. A criao de um processo completo e prtico para atingir metas a rea mais crtica da implementao de SOA, pois imprescindvel determinar como a governana ser obtida, respeitando a realidade da empresa e sua cultura de gerenciamento. A governana SOA visa elevar a qualidade de SOA em ambientes diferentes. Este trabalho no teve como objetivo esgotar todos os conceitos e assuntos disponveis na literatura sobre o tema apresentado, mas sim servir como uma fonte de anlise e/ou um ponto de partida para outros trabalhos que possam abordar de forma mais investigativa cada um dos pontos levantados aqui. Como sugesto para prximos trabalhos poderia ser feito estudo de ferramentas que suportam a governana SOA, tal como, o Enterprise Repository da ORACLE na verso 11g. .

FACULDADE PITGORAS DE UBERLNDIA

Referncias Bibliogrficas

BAM Business Activity Monitoring: inteligncia de negcios em tempo-real. Disponvel em: <http://uni.com.br/knowledge_base/?p=267/>. Acesso em: 07 out 2011.

BOMBARDA, Marcelo A. Soa (Arquitetura Orientada a servios). Disponvel em: < http://www.artigonal.com/ti-artigos/soa-arquitetura-orientada-a-servicos535681.html/>. Acesso em: 19 maio 2011.

BRAGA, Bruno. SOA Resumo de Palestras. Disponvel em: <http://www.brunobraga.com.br/2007/05/02/soa-resumo-de-palestras/>. Acesso em: 14 julho 2011.

CARVALHO, Carlos Augusto da Costa. O que governana de TI? Disponvel em: < http://itweb.com.br/voce-informa/o-que-e-governanca-de-ti/ >. Acesso em:

FOINA, Paulo Rogrio. Um pouco sobre SOA. Disponvel em: <http://www.cpd.com.br/publicacoes/um-pouco-sobre-soa/>. Acesso em: 15 julho 2011.

FUSCO, Camila. Qual o perfil ideal de um projeto de SOA? Disponvel em: <http://cio.uol.com.br/gestao/2007/09/28/idgnoticia.2007-0928.7623630583/#ir/>. Acesso em 14 jul. 2011.

GERRARD, M. Criando um processo efetivo de governana em TI. Disponvel em:<http://info.abril.com.br/corporate/gartner/criando-um-processo-efetivo-degovernanca-em-ti-1.shtml />. Acesso em 13 jul. 2011.

HOLL, Rodrigo. Definio de SOAP. Disponvel em: <http://rodrigoholl.blogspot.com/2010/09/definicao-de-soap.html/>. Acesso em: 27 jul. 2011.

INAZAWA, Rafael Rayato. A aplicao do BPM para automao de processos de negcio nas organizaes. Estudo de caso: Projeto NEW_RCMS. In: Monografia apresentada no curso de Tecnologia em Informtica com nfase em Gesto de negcios na FATEC ZL como requerimento parcial na obteno

FACULDADE PITGORAS DE UBERLNDIA

do ttulo de Tecnlogo em informtica com nfase em gesto de negcios. 2009, So Paulo. Disponvel em: < http://www.fateczl.edu.br/TCC/2009-2/tcc47.pdf/>. Acesso em 07 nov. 2011

KOCH, Christopher. ABC DA SOA. Disponvel em: <http://cio.uol.com.br/tecnologia/2006/07/17/idgnoticia. 2006-0717.3732358054/>. Acesso em: 17 maio 2011.

LEAVER, Sharyn. Os verdadeiros motivos do desentendimento entre TI e negcios. Publicada em 14 de janeiro de 2010. Disponvel em: <http://cio.uol.com.br/opiniao/2010/01/12/os-verdadeiros-motivos-dodesentendimento-entre-ti-e-negocios/#ir/>. Acesso em: 14 julho 2011.

LEE, Helder Mah. Integrao de Sistemas com SOA e BPM. Disponvel em: <http://www.assembla.com/spaces/senac_tcc_soa/documents/cOMY0QSaSr3R JMeJe5aVNr/>. Acesso em: 17 maio 2011.

MANES, Anne Thomas. Understanding SOA Governance. Disponvel em: <http://www.soamag.com/I40/0610-2.php/>. Acesso em: 11 agosto 2011.

MARTINS, V. M. M. Integrao de Sistemas de Informao: Perspectivas, normas e abordagens. In: Dissertao de Mestrado apresentada no Programa de Ps Graduao em Sistemas de Informao da Universidade do Minho, 2005, Portugal. Disponvel em: < http://repositorium.sdum.uminho.pt/bitstream/1822/5657/3/tese_mestrado_victo r_martins_2005.pdf/>. Acesso em: 10 jun. 2011

MITRA, Tilak. A case for SOA governance. Disponvel em: <http://www.ibm.com/developerworks/webservices/library/ws-soa-govern/>. Acesso em: 11 ago. 2011

PRADO, Leandro. Ferramentas SOA Open Source. Disponvel em:<http://www.leandroprado.com.br/2010/05/ferramentas-soa-open-source/>. Acesso em 14 jul. 2011.

SANTOS, Wallace. Compreendendo a Arquitetura Orientada a Servios (SOA). Disponvel em: < http://surferdotnet.blogspot.com/2007/02/compreendendoarquitetura-orientada.html/>. Acesso em: 17 maio 2011.

FACULDADE PITGORAS DE UBERLNDIA

SCHEPERS, Tom; KRATZ, Benedikt. Maturidade em Governana SOA: A Viso de um Arquiteto. Trad. Leonardo Luz. Disponvel em: <http://www.infoq.com/br/articles/soa-gov-architect-s-view/>. Acesso em: 11 ago. 2011.

SENSEDIA. Solues | SOA (Arquitetura Orientada a Servios). Disponvel em: <http://www.sensedia.com/br/soa/> Acesso em: 14 jul. 2011.

SILVA, Hugo. Service-Oriented Architectures e Interoperabilidade de aplicaes utilizando Web-Services. In: Relatrio de projeto apresentado no Programa de Licenciatura de Engenharia Informtica do Instituto Superior de Engenharia do Porto, 2004, Portugal. Disponvel em: <http://www.dei.isep.ipp.pt/~paf/proj/Set2004/RelatorioSOA-final.pdf/>. Acesso em: 31 out. 2011.

Wikipdia, a enciclopdia livre. XML Schema. Disponvel em: http://pt.wikipedia.org/wiki/XML_Schema/> Acesso em: 22 jul. 2011.