artigo import an cia da governanca soa

8/3/2019 ARTIGO Import an CIA Da Governanca SOA

1/31

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: [email protected]

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: [email protected]


2/31


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.


3/31


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.


4/31


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 Middlewarecorresponde a uma arquitectura

tecnolgica que concentra num software centralizado um conjunto de

informao, procedimentos e aplicaes. Este permite interligar sistemas,


5/31


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 aoreescrever 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 denegcio 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.


6/31


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 componentese 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 umarequisio 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 etambm descreve como sendo um componente, uma parte de desenvolvimento


7/31


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 middlewaresde 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 Santos (2007) SOA no uma arquitetura baseada

exclusivamente em Web Services, mas os Web Servicesso a melhor maneira

de alcanar os fundamentos de SOA, e provavelmente por isso que asimplementaes so vistas atravs do uso de Web Services

Santos (2007) menciona que a Arquitetura Orientada a Servios baseia-

se 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 automaodo 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.


8/31


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 oferecidaspelo 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 servicespodemser compostos com a finalidade de oferecer novos servios.


9/31


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 ecada 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 quaisesto em pausa (PRADO, 2010).


10/31


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 Protocolconsiste em um protocolo para trocade informaes estruturadas em uma plataforma descentralizada edistribuda utilizando tecnologias baseadas em XML. utilizado parainvocar aplicaes remotas ou Web Services atravs de RPC(Chamadas Remotas de Procedimentos) ou troca de mensagens emambiente 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,


11/31


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 camposbinrios quando representados em formato baseado em XML, causando


12/31


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 ocusto 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 umusurio, um dispositivo fsico ou um requisitante de servioexterno.

Autorizao: determina o que uma identidade tem permissode fazer.

Confidencialidade: assegura que apenas aquele que chamouo servio possa ver os dados enquanto esto sendotransferidos entre o fornecedor e o consumidor.

Integridade: impede que dados sejam manipulados oufalsificados de forma que se tornem incorretos.

Disponibilidade: evita que os servios se tornem inoperantes

por meio de contramedidas a ataques tais como os denegao de servio (DoS Denial of Service).


13/31


Contabilizao: significa monitorar as chamadas de serviopara gerenciamento, planejamento e outros propsitos.

Auditoria: registro de informaes relevantes segurana,para permitir deteco e anlise de falhas de segurana eataques. Envolve tambm registro de informaes legaisquando for o caso.A melhor maneira de lidar com segurana em SOA fornec-la como um servio:

SES (Security Enforcement Services; servio de reforo desegurana) que de dentro de um ESB ou de um aplicativochamam um SDS.

SDS (Security Decision Service; servio de deciso desegurana).

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 erelacionamentos estruturados, assumidos por executivos, gestores,tcnicos e usurios de TI de uma organizao, com a finalidade degarantir controles efetivos, ampliar os processos de segurana,minimizar os riscos, ampliar o desempenho, otimizar a aplicao derecursos, 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.


14/31


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 dedeciso. 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 prometidospela 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 garantemos servios de suporte a protocolos comuns e modelos de dados


15/31


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:


16/31


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 daempresa 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 recursosfinanceiros 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 umpr-requisito primordial para o desenvolvimento dos princpios e reas de


17/31


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 umaempresa 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


18/31


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 defrum mais efetivo para colaborao. O tipo de informao necessria para a tomada de deciso Quais fruns consultivos devem dar informaes para quem toma adeciso. As atividades e responsabilidades dos membros da equipe. Quais atividades de suporte sero necessrias para fazer oprocesso funcionar. Os produtos finais que sero entregues.

Aps a definio dessas trs grandes reas, a implementao do projetopoder 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 entreas 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


19/31


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 sejacriado para alcanar as metas estabelecidas para a governana.Esse processo deve identificar o estilo de tomada de deciso, acultura e as prticas da empresa, alm de estabelecer etapas de

ao, papis dos envolvidos, responsabilidades e produtos finais eintermedirios a ser entregues.Embora a governana possa ser a forma de incluir somente aatribuio de direitos de deciso e responsabilidades finaispertinentes, na prtica ela deveria considerar uma diversidade deresponsabilidades que atualmente so vistas de forma superficial,como critrios de controle e deciso, atividades de gerenciamento eatribuies de direitos de deciso. Os gerentes de TI que se propema desenvolver um processo de governana mais efetivo deveriamcomear por considerar a governana de TI como um conjunto deprocessos 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.


20/31


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 queatuam 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 denegcio 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 a determinao dos papis e

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


21/31


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


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 dacorporao. 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 paradesenvolvimento de servios denominam-se princpios em tempo de design e


22/31


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


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 deregistry, 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 problemasque 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.


23/31


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 oadiamento 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 oplanejamento 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 sercompletamente compreendido para que os benefcios alcanados por seu


24/31


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 serviosda 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 demeta-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.


25/31


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 resultadosalmejados.

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:


26/31


Nvel de patrocnio: composto pelas partes interessadas no comit

de direo e sua representao determinada pelos membros do c-suiteque

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 sercumpridas 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


27/31


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 da

estrutura.

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 custo-

benefcio 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.


28/31


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.

.


29/31


Referncias Bibliogrficas

BAM Business Activity Monitoring:inteligncia de negcios em tempo-real.Disponvel em: . Acesso em: 07out 2011.

BOMBARDA, Marcelo A. Soa (Arquitetura Orientada a servios). Disponvelem: .Acesso em: 19 maio 2011.

BRAGA, Bruno. SOA Resumo de Palestras. Disponvel em:. Acessoem: 14 julho 2011.

CARVALHO, Carlos Augusto da Costa. O que governana de TI?Disponvelem: < http://itweb.com.br/voce-informa/o-que-e-governanca-de-ti/>. Acessoem:FOINA, Paulo Rogrio. Um pouco sobre SOA. Disponvel em:. Acesso em: 15julho 2011.

FUSCO, Camila. Qual o perfil ideal de um projeto de SOA?Disponvel em:. Acesso em 14 jul. 2011.

GERRARD, M. Criando um processo efetivo de governana em TI. Disponvel

em:. Acesso em 13 jul. 2011.

HOLL, Rodrigo. Definio de SOAP. Disponvel em:. Acesso em:27 jul. 2011.

INAZAWA, Rafael Rayato. A aplicao do BPM para automao de processosde negcio nas organizaes. Estudo de caso: Projeto NEW_RCMS. In:

Monografia apresentada no curso de Tecnologia em Informtica com nfaseem Gesto de negcios na FATEC ZL como requerimento parcial na obteno


30/31


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/tcc-47.pdf/>. Acesso em 07 nov. 2011

KOCH, Christopher. ABC DA SOA. Disponvel em:. Acesso em: 17 maio 2011.

LEAVER, Sharyn. Os verdadeiros motivos do desentendimento entre TI enegcios. Publicada em 14 de janeiro de 2010. Disponvel em:. Acesso em: 14 julho 2011.

LEE, Helder Mah. Integrao de Sistemas com SOA e BPM. Disponvel em:. Acesso em: 17 maio 2011.

MANES, Anne Thomas. Understanding SOA Governance. Disponvel em:. Acesso em: 11 agosto 2011.

MARTINS, V. M. M. Integrao de Sistemas de Informao:Perspectivas,normas eabordagens. In: Dissertao de Mestrado apresentada no Programade Ps Graduao em Sistemas de Informao da Universidade do Minho,2005, Portugal. Disponvel em: . Acesso em: 10 jun. 2011

MITRA, Tilak. A case for SOA governance. Disponvel em:.Acesso em: 11 ago. 2011

PRADO, Leandro. Ferramentas SOA Open Source.Disponvelem:.Acesso em 14 jul. 2011.

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


31/31


SCHEPERS, Tom; KRATZ, Benedikt. Maturidade em Governana SOA:AViso de um Arquiteto. Trad. Leonardo Luz. Disponvel em:. Acesso em: 11ago. 2011.

SENSEDIA. Solues | SOA (Arquitetura Orientada a Servios). Disponvel em: Acesso em: 14 jul. 2011.

SILVA, Hugo. Service-Oriented Architectures e Interoperabilidade deaplicaes utilizando Web-Services. In: Relatrio de projeto apresentado noPrograma de Licenciatura de Engenharia Informtica do Instituto Superior deEngenharia do Porto, 2004, Portugal. Disponvel em:. Acessoem: 31 out. 2011.

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

artigo import an cia da governanca soa

Documents