Plano Implantacao Pereira PDF

Plano de implantao de uma arquitetura orientada
a servios SOA - na Cmara dos Deputados
Antonio Jos de Souza Pereira
2012
Biblioteca Digital da Cmara dos Deputados

Centro de Documentao e Informao
Coordenao de Biblioteca
http://bd.camara.gov.br
"Dissemina os documentos digitais de interesse da atividade legislativa e da sociedade.

Centro Universitrio do Distrito Federal UDF
Ps-Graduao Pesquisa e Extenso
Especializao em Governana em TI no Setor Pblico
Plano de implantao de uma arquitetura orientada a

servios SOA - na Cmara dos Deputados
Braslia DF
2012
Plano de implantao de uma arquitetura orientada a

servios na Cmara dos Deputados
Trabalho de concluso de curso

apresentado a Ps Graduao,
Pesquisa e Extenso do Centro
Universitrio do Distrito Federal - UDF,
como requisito parcial para obteno do
ttulo de Especialista - MBA em
Governana de Tecnologia da
Informao no Servio Pblico, sob a
orientao do MSc. Prof. Flvio Feitosa
Costa
Braslia 02 de janeiro de 2012

Errata
Plano de implantao de uma Arquitetura Orientada

a Servios SOA - na Cmara dos Deputados
Trabalho de concluso de curso

apresentado a Ps Graduao,
Pesquisa e Extenso do Centro
Universitrio do Distrito Federal - UDF,
como requisito parcial para obteno do
ttulo de Especialista - MBA em
Governana de Tecnologia da
Informao no Servio Pblico, sob a
orientao do MSc. Prof. Flvio Feitosa
Costa
Braslia 2 de janeiro de 2012.
BANCA EXAMINADORA
__________________________________________
Flvio Feitosa Costa
MSc. PMP
Centro Universitrio do Distrito Federal
Nota: ______
Dedico este trabalho a minha esposa e filhos
que procuram compreender minha ausncia
durante o longo perodo dedicado s atividades
acadmicas.
AGRADECIMENTO
Agradeo a meus pais, Jos Manoel Pereira e Eliza
de Souza Pereira, pelos fundamentos de carter e
tica to arduamente ensinados e a todos os meus
mestres, que encarnados em professores, amigos e
colegas dos mais diferentes crculos de ao e
convivncia sempre estiveram presentes me
incentivando ao crescimento e aprendizado
contnuos.
Embora ningum possa voltar atrs e fazer
um novo comeo, qualquer um pode comear
agora e fazer um novo fim.
Francisco Cndido Xavier.

RESUMO
Este trabalho tem por objetivo apresentar um plano para implantao de uma
Arquitetura Orientada a Servios SOA, na Cmara dos Deputados Brasil. O
plano de implantao SOA foi estruturado em dois projetos: Entender SOA e
Implantar SOA, descritos em suas macro atividades e foi embasado em um
arcabouo terico fundamentado em significativa literatura pesquisada que incluiu os
modelos de referncia e de arquitetura SOA disponveis. Foram abordados, alm
dos aspectos tecnolgicos, as questes de Governana de TI e questes de cultura
organizacional que precisam ser consideradas em projetos dessa natureza,
considerando que SOA no simplesmente uma questo de tecnologia, mas
fundamentalmente uma questo de negcio e Governana Empresarial. Os
aspectos de TI tambm foram explorados de forma suficiente para que as equipes
tcnicas tenham condies de implementar os princpios de desenho da arquitetura
SOA.
Palavras chave: SOA. Governana de TI. BPM. Arquitetura Orientada a Servios.

Gesto Estratgica. Cmara dos Deputados - Brasil. Centro de Informtica CENIN.
ABSTRACT
This paper aims to present a plan for deploying a Service Oriented Architecture -
SOA, the Chamber of Deputies - Brazil. The SOA deployment plan was structured in
two projects: "Understanding SOA" and "Deploy SOA" as described in its macro
activities and was based on a theoretical framework based on a significant literature
that included the reference models and SOA architecture available. Were discussed,
in addition to technological aspects, the issues of IT governance and organizational
culture issues that must be considered in projects of this nature, considering that
SOA is not simply a technology issue, but fundamentally a matter of business and
corporate governance. The IT aspects have also been exploited enough that the
technical teams are able to implement the design principles of SOA.
Keywords: SOA. IT Governance. BPM. Service Oriented Architecture. Strategic

Management. Chamber of Deputies - Brazil. Computer Center - CENIN.
Lista de Abreviaturas e/ou siglas
ABPMP Association of Business Process Management Professionals

Associao dos Profissionais de Gerenciamento de Processos de
Negcio
APROGE Assessoria de Projetos e Gesto Estratgica
BPMS Business Process Management System Sistema de Gerenciamento

de Processos de Negcio
CBOK BPM Common Body of Knowledge Base de Conhecimento BPM
CCS Centro de Competncia SOA
CENIN Centro de Informtica da Cmara dos Deputados
CIO Chief information officer Chefe de Tecnologia da Informao TI
IEEE IEEE Computer Society Organizao dedicada ao avano da teoria

e aplicao da informtica e tecnologia da informao
OASIS Organizao para o Avano de Padres de Informao Estruturada
SOA Services Oriented Architecture Arquitetura Orientada a Servios
TI Tecnologia da Informao
Lista de Figuras e Tabelas
Figura 1 - Principais conceitos do Modelo de Referncia.......................................... 32
Figura 2- Organograma da Cmara dos Deputados ................................................. 51
Tabela 1 - Comparativo de princpios de orientao a servios ................................ 30
Tabela 2 - Quadro resumo do Modelo de Referncia SOA ....................................... 34
Tabela 3 - Ingredientes SOA - (JOSUTTIS, 2008) .................................................... 36
Tabela 4 - Estgios do ciclo de vida SOA (HIGH, KINDER e GRAHAM, 2005) ........ 37
Tabela 5 Questes essenciais para deciso de TI - (WEILL e ROSS, 2006)......... 40
Tabela 6- Papis e Responsabilidades propostos por Bieberstein (2006) para

implementao de SOA............................................................................................. 43
Tabela 7- Exemplo de um formato para formulao de polticasSOA (JOSUTTIS,

2008, p. 237) ............................................................................................................. 44
Tabela 8 - Vantagens do modelo de desenvolvimento tradicional (ERL, 2009) ........ 45
Tabela 9 - - Desvantagens do desenvolvimento de sistemas tradicional (ERL, 2009)

.................................................................................................................................. 46
Tabela 10 - Os quatro nveis arquitetnicos propostos por Ross (2006) ................... 47
Tabela 11 - Estgios de maturidade de arquitetura ................................................... 49
Tabela 12 - Atributos para um Catlogo de Servios simplificado ............................ 75

SUMRIO
1 INTRODUO.............................................................................................. 13
1.1 Tema ........................................................................................................... 13
1.2 Contexto ....................................................................................................... 15
1.2.1 Gesto por Processos .................................................................................. 16
1.2.2 Criao do Ncleo de Integrao - SECOMP ............................................... 17
1.3 DELIMITAO DO PROBLEMA .................................................................. 17
1.4 Formulao do Problema.............................................................................. 18
1.5 Objetivos ....................................................................................................... 18
1.5.1 Objetivo Geral ............................................................................................... 18
1.5.2 Objetivos Especficos ................................................................................... 18
1.5.3 Metodologia .................................................................................................. 19
2 REFERENCIAL TERICO ........................................................................... 20
2.1 Arquitetura Orientada a Oervios SOA ...................................................... 20
2.1.1 Conceituando Arquitetura ............................................................................. 20
2.1.2 Servios ........................................................................................................ 22
2.1.3 Comparando os modelos de implementao de Erl e Josuttis ..................... 29
2.1.4 Arquitetura Orientada a Servios .................................................................. 30
2.1.5 OASIS e o Modelo de Referncia SOA. ....................................................... 31
2.1.6 Josuttis (2008) e os ingredientes chave de SOA ........................................ 35
2.1.7 Os Fundamentos para a arquitetura SOA OASIS Julho/2011. ............... 37
2.2 Governana de ti e governana de SOA ...................................................... 38
2.2.1 O Centro de Competncia SOA - CCS ......................................................... 41
2.2.2 Papis e responsabilidades SOA ................................................................. 42
2.2.3 Polticas SOA................................................................................................ 43

2.3 SOA na organizao e o papel da TI ............................................................ 44
2.4 MATURIDADE DA ARQUITETURA DE TI ................................................... 47
2.5 SOA E BPM .................................................................................................. 49
3 ANLISE CRTICA E DESENVOLVIMENTO ............................................... 51
3.1 Contexto ....................................................................................................... 51
3.1.1 A estrutura organizacional da Cmara dos Deputados ................................ 51
3.1.2 Estrutura funcional do Centro de Informtica................................................ 53
3.1.3 Gesto estratgica e estruturas de governana na Cmara dos Deputados 55
3.1.4 Planejamento Estratgico do Centro de Informtica da Cmara dos

Deputados .................................................................................................... 58
3.1.5 Resumo das principais caractersticas de contexto atual do Centro de

Informtica da Cmara dos Deputados ........................................................ 60
3.2 Plano de projeto para implantao da SOA .................................................. 62
3.2.1 Projeto 1: Entender SOA .............................................................................. 63
3.2.2 Projeto 2: Implantar SOA .............................................................................. 69
3.2.3 Consideraes Finais ................................................................................... 74
4 CONCLUSO ............................................................................................... 77
5 BIBLIOGRAFIA CONSULTADA ................................................................... 79

1 INTRODUO
Este trabalho de concluso de curso (TCC) apresenta uma proposta de

um plano de implantao de Arquitetura Orientada a Servios SOA na Cmara dos
Deputados. Sero apresentados os principais conceitos e padres que definem a
arquitetura de forma a sustentar um plano de implantao que dever considerar em
primeiro plano os aspectos de governana organizacional e de tecnologia da
informao.
Embora focado principalmente no ambiente organizacional da Cmara

dos Deputados, o plano proposto rene conceitos e estratgias aplicveis em
qualquer organizao principalmente s do servio pblico.
1.1 TEMA
Nas ltimas 2 dcadas pudemos verificar o grande crescimento dos

departamentos de TI, tanto na rea pblica, como na iniciativa privada, numa
profuso de sistemas e plataformas computacionais suportando os mais diversos
processos de negcio.
Metodologias, processos e arquiteturas se sucederam buscando conferir

maior agilidade e efetividade na construo de solues para problemas e
processos cada vez mais complexos.
No incio, regra geral, as solues de sistemas eram construdas para

atender a departamentos ou processos especficos, sem grandes possibilidades de
integrao com outros sistemas e sem grandes preocupaes com o reuso. Eram
sistemas monolticos, funcionais, difceis de manter e de evoluir, apoiando processos
relativamente estveis.
Em seu livro SOA Princpios de design de servios, Thomas Erl

descreve tambm esse cenrio ao apresentar um estudo de caso da Cutit Saws
Ltda uma empresa dedicada fabricao de lminas de corte. Nas palavras do
autor: O ambiente de TI da Cutit uma confuso de servidores e estaes de
trabalho. Hardwares e softwares so comprados conforme a necessidade pelos
diferentes departamentos (ERL, 2009).
Ainda segundo o autor, um dos diretores e fundadores da empresa, com
formao em cincia da computao, foi o desenvolvedor dos sistemas de
contabilidade e estoques.
As solues caseiras desenvolvidas, conforme relata o autor, comearam,

depois de algum tempo, a apresentar problemas de desempenho e de uso
concorrente. Quando a empresa precisou ampliar seus negcios e se adaptar s
novas condies de mercado, percebeu que os modelos e arquiteturas utilizadas
para automao de seus processos eram rgidos e incapazes de responder aos
novos desafios do mercado, o que ameaava a sobrevivncia da prpria
organizao. No entanto, desenvolver novos sistemas seria muito caro e arriscado.
Esse cenrio parece ser muito comum em grande parte das empresas
pblicas e privadas. Apesar de rgidos e muitas vezes at ultrapassados, sistemas
legados representam grandes investimentos j realizados. Muitas vezes quase
invivel, tanto por questes de tempo como pelos custos envolvidos, refazer essas
aplicaes, mesmo quando tal medida se mostra inadivel.
Integrar sistemas atravs de uma arquitetura orientada a servios e

desenvolver novas aplicaes com base nessa nova abordagem, parece ser a forma
mais adequada de preservar investimentos realizados, prevenir o desperdcio na
construo de novas aplicaes, integrar novos sistemas a sistemas legados,
suportar as tendncias de gesto por processos, gesto de contedo e assim por
diante.
Muitos autores se dedicaram a estabelecer modelos para uma arquitetura

orientada a servios com padres de desenho, boas prticas, arquitetura, etc.
Mas a questo como iniciar a implantao de uma arquitetura orientada

a servios em uma empresa com seu parque computacional j estabelecido, com
sistemas aparentemente estveis, mesmo que obsoletos, com problemas culturais a
serem enfrentadas, novas aquisies e mudana de paradigma.
Esse trabalho de concluso de curso procura alinhar os principais pontos

de ateno para a formulao de um plano para implantao de uma arquitetura
orientada a servios em uma organizao conhecida, com a elaborao de um
projeto de implantao que considere no s as questes tcnicas da arquitetura
SOA, mas tambm as questes culturais e de governana.
1.2 CONTEXTO
O Centro de Informtica da Cmara dos Deputados (CENIN) foi criado em

janeiro de 1997 atravs do Ato da Resoluo 16, de 1997.
Suas primeiras iniciativas de desenvolvimento de aplicativos foram

voltadas para o desenvolvimento de sistemas de apoio ao processo legislativo; folha
de pagamento; atividade parlamentar; consultas base de dados de legislao e
material e patrimnio.
Posteriormente, logo nos primeiros anos de suas atividades, o CENIN

desenvolveu aplicaes para diversas outros processos administrativos, como: cotas
parlamentares; manuteno e fornecimento de imveis para ocupao pelos
deputados; painel eletrnico de votao; emisso de passaporte parlamentar; e
muitos outros.
As aplicaes, em sua maioria, eram desenvolvidas em plataforma

cliente-servidor, com utilizao de Visual Basic 6 (VB6) e componentes COM++.
Alguns sistemas foram desenvolvidos em plataforma web, utilizando

linguagem ASP ainda com a utilizao de componentes COM++.
O grande impulso das tecnologias relacionadas internet, com a

necessidade de criao de pginas para a web informativas, ocorrido entre o final da
dcada de 1990 e os primeiros anos da dcada de 2000 indicou a necessidade de
maior especializao de um segmento de desenvolvedores do CENIN para essa
nova plataforma.
Novas necessidades foram identificadas, como a especializao para o

painel eletrnico de votao, reformulao da folha de pagamento e aplicaes
administrativas diversas, sendo ento criados diversos ncleos de desenvolvimento
para cada necessidade.
Em 2002, a Cmara dos Deputados j contava com trs bancos de dados

corporativos: INGRES, SQL Server e Oracle e as aplicaes estavam dispersas
nessas trs plataformas, compartilhando alguns dados atravs de replicaes que
no se limitavam apenas aos Sistemas Gerenciadores de Bancos de Dados
(SGBD), mas tambm entre aplicativos diferentes em cada SGBD.
Em 2003 a Coordenao de Desenvolvimento de Sistemas, uma das
coordenaes responsveis pela construo de aplicativos iniciou esforos para a
definio de um processo de desenvolvimento baseado no Processo Unificado e
direcionando as novas aplicaes para a plataforma J2EE.
Em 2011, a Cmara dos Deputados conta com aplicaes desenvolvidas

em Visual Basic, ASP e Java. Existem diversos bancos de dados com informaes
redundantes e divergentes entre si, com um alto custo de manuteno para as
aplicaes, dificuldades para evoluo dos sistemas que comeam a mostrar sinais
de obsolescncia.
So, em geral, aplicaes focadas em departamentos e processos muito

especficos com baixssimas possibilidades de integrao com outros sistemas,
reimplementando funcionalidades bsicas como gesto de identidade e acesso e
manuteno de dados corporativos, com uma viso muito limitada de processos
horizontalizados, que permitam a colaborao entre os diversos departamentos da
rea administrativa.
1.2.1 Gesto por Processos
Em 2009 o planejamento estratgico da Cmara dos Deputados

estabeleceu a gesto de processos como um de seus objetivos. Dois sistemas
iniciaram o seu ciclo de desenvolvimento partindo de uma abordagem de
desenvolvimento orientado a processos, com bases em processos modelados pelas
reas de negcios, utilizando um BPMS.
Logo nas primeiras iniciativas de automao ficaram evidentes as

necessidades de consumo de dados de alguns sistemas legados, o que aumentou
consideravelmente o risco para os projetos de desenvolvimento desses sistemas.
A arquitetura monoltica dos sistemas legados e a cultura de integrao

entre esses sistemas atravs do acesso, replicao ou mesmo duplicao de dados
mostrou-se totalmente ineficiente para uma abordagem de desenvolvimento
orientado a processos, evidenciando a necessidade de integrao atravs de uma
camada de servios que permitisse a colaborao entre os diversos sistemas.
1.2.2 Criao do Ncleo de Integrao - SECOMP
Para tentar contornar os problemas de integrao entre sistemas e

viabilizar o modelo de desenvolvimento orientado a processos, a Coordenao de
Engenharia de Sistemas resolveu criar um pequeno ncleo de integrao, a Seo
de Administrao de Componentes e Processos (SECOMP), cujo objetivo inicial
seria incentivar a criao de componentes de negcio catalogados e gerenciados
por esse mesmo ncleo.
Essa parece ser uma abordagem bastante comum para integrao entre
sistemas, mas ainda no suficiente para enfrentar todos os desafios.
Alis, mas do que integrao, a gesto de processos aponta para a

construo de uma arquitetura orientada a servios, que poder ser o prximo passo
na evoluo da rea de sistemas do Centro de Informtica da Cmara dos
Deputados.
A adoo de uma arquitetura orientada a servios parece ser uma boa

alternativa para dar mais flexibilidade e agilidade aos sistemas, apoiar a integrao
de sistemas legados e as iniciativas de gesto por processos.
No entanto, sua implantao no trivial. Mais do que os aspectos

tcnicos ela envolve questes culturais, novos modelos de desenvolvimento e
mudana de paradigma no desenvolvimento de sistemas. Por isso, tal mudana
precisa ser conduzida por um projeto bem elaborado, que minimize os riscos de
fracasso do empreendimento, que poderia trazer como consequncia o descrdito
dos desenvolvedores na arquitetura orientada a servios, perdendo-se assim a
janela de oportunidade e adiando por tempo indeterminado a adoo do novo
modelo.
1.3 DELIMITAO DO PROBLEMA
Com este trabalho iremos propor um plano de implantao de uma

arquitetura orientada a servios (SOA), para o Centro de Informtica da Cmara dos
Deputados, considerando aspectos culturais e de governana especficos.
1.4 FORMULAO DO PROBLEMA
A Cmara dos Deputados conta hoje com cerca de 200 sistemas

desenvolvidos em diferentes linguagens de programao, servidores de aplicao e
gerenciadores de bancos de dados.
A profuso de sistemas e dados gerou ao longo do tempo grande

redundncia e inconsistncias entre as diferentes bases de dados, com graves
dificuldades para integrao entre sistemas e principalmente para a evoluo dos
sistemas legados e desenvolvimento de novas aplicaes.
As dificuldades tornam-se mais evidentes com a adoo de modelos de

desenvolvimentos orientados a processos e a necessidade de adaptao do centro
de informtica s diretrizes estratgicas de gesto de processos.
Uma das alternativas a adoo de uma arquitetura orientada a servios

(SOA), que representa uma mudana de paradigma de desenvolvimento para o
Centro de Informtica.
Nesse cenrio, a implantao de SOA precisa estar apoiada em um plano

bem elaborado que minimize os riscos de fracasso na implantao, o que poderia
atrasar por tempo indeterminado a soluo dos problemas apontados.
1.5 OBJETIVOS
1.5.1 Objetivo Geral
Elaborar um plano de implantao de uma Arquitetura Orientada a

Servios para a Cmara dos Deputados.
1.5.2 Objetivos Especficos
a) Apresentar as principais caractersticas tcnicas da arquitetura SOA, que

precisaro ser implementadas
b) Avaliar as questes de governana e gerenciamento a serem considerados no
projeto de implantao.
c) Elaborar o plano de implantao de SOA na Cmara dos Deputados
1.5.3 Metodologia
Para elaborao deste trabalho sero consultadas fontes bibliogrficas

sobre os padres de desenho e arquitetura orientados a servios e governana
SOA.
As questes culturais e estratgicas que formam o contexto

organizacional da Cmara dos Deputados, sero avaliadas a partir da
documentao disponvel no prprio sitio web da Organizao.
Ao final ser formulado um plano para implantao de SOA baseado em

projetos a serem executados e que considera os aspectos tcnicos, culturais e de
governana estudados.
2 REFERENCIAL TERICO
2.1 ARQUITETURA ORIENTADA A OERVIOS SOA
Nos ltimos anos, a Arquitetura Orientada a Servios SOA vem sendo

apresentada como importante estratgia para incremento de produtividade e
competitividade das empresas. Ela uma abordagem que ajuda os sistemas a
permanecerem escalveis e flexveis enquanto crescem, e que tambm ajuda a
resolver a lacuna negcio/TI. (JOSUTTIS, 2008, p. 1) No entanto, o significado
exato do termo, suas implicaes no modelo de desenvolvimento de sistemas e na
prpria arquitetura de TI parece no estar suficientemente claro para boa parte das
organizaes e profissionais envolvidos.
[...] o termo Arquitetura Orientada a Servios e sua sigla associada so

utilizados to amplamente pela mdia e na literatura de marketing dos
fornecedores, que se tornou quase um sinnimo para a prpria computao
orientada a servios. , portanto, muito importante fazer uma distino clara
entre o que a SOA e de fato e como ela se relaciona com outros elementos
da computao orientada a servios. (ERL, 2009, p. 24)
2.1.1 Conceituando Arquitetura
Para a IEEE 1471, arquitetura a organizao fundamental de um

sistema incorporado em seus componentes, suas relaes comuns aos outros e ao
meio ambiente e os princpios orientadores da sua concepo e evoluo. (MAIER,
EMERY e HILLIARD, 2000, p. 6)
A arquitetura de sistemas existe no plano conceitual. Isso significa que

todo sistema organiza-se fundamentalmente em uma arquitetura, quer tenha sido ela
explicitamente desenhada ou no.
Entretanto, a descrio de uma arquitetura no a prpria arquitetura,

mas uma descrio, segundo um ponto de vista.
Uma arquitetura articulada do ponto de vista das partes interessadas

onde seus interesses determinam a sua aptido para uma finalidade, e tudo isso
deve ser entendido no seu contexto ambiental. (MAIER, EMERY e HILLIARD, 2000).
A descrio de uma arquitetura deve considerar viso e pontos de vista
dos interessados. Viso refere-se ao que est sendo observado e ponto de vista
refere-se posio do observador.
Assim, de acordo com o estudo realizado por High (2005, p. 13), na

perspectiva do negcio, SOA trata da modelagem do negcio, incluindo desenho e
refinamento dos processos.
Nessa linha, ainda segundo o autor, Os arquitetos de sistemas de

informao iro descrever SOA como um estilo de arquitetura que estrutura artefatos
de sistemas de informao como um conjunto de servios que podem ser agrupados
para formar outros servios ou mesmo como um conjunto de princpios para o baixo
acoplamento, modularidade, reuso, etc para alcanar objetivos relacionados a
ganhos de produtividade e competitividade para o negcio. (HIGH, KINDER e
GRAHAM, 2005)
Continuando nesse raciocnio, na perspectiva dos programadores, SOA

seria um conjunto modelos de programao e ferramentas para construir, acessar e
desenvolver servios que implementam o desenho de negcio. (HIGH, KINDER e
GRAHAM, 2005, p. 13)
Numa arqutetura orientada a servios, no estamos nos referindo apenas

s questes de tecnologia da informao, mas prpria estrutura da organizao,
na forma como os servios sero identificados e automatizados, como iro agregar
valor, como sero governados e gerenciados. Naturalmente, a descrio da
arquitetura orientada a servios ir variar em abordagem, conforme observada por
interessados no nvel estratgico, ttico ou gerencial, e ainda pelas equipes de TI.
No entanto, preciso que haja um entendimento integrado e coerente a respeito
desses diferentes pontos de vista.
Stal afirma que melhores implementaes de SOA so obtidas quando os

desenvolvedores entendem esse paradigma por uma perspectiva de arquitetura.
Para ele, o objetivo central de uma abordagem de Orientao a Servios reduzir
as dependncias entre as chamadas ilhas de software. (STAL, 2006, p. 55)
Para Josuttis, SOA no uma ferramenta ou framework que se possa

comprar. uma abordagem, uma maneira de pensar, um sistema de valores que
leva a certas decises concretas quando se projeta uma arquitetura de software.
(JOSUTTIS, 2008, p. 12)
2.1.2 Servios
A OASIS define servios como um mecanismo para habilitar o acesso a

uma ou mais competncias, fornecidas por um provedor de servio, com base em
uma interface e uma descrio que inclui polticas e restries de uso.
(MACKENZIE, LASKEY, et al., 2006, p. 13)
Erl (2009) afirma que servios existem como programas de software

fisicamente independentes, com caractersticas de design distintas. Esses servios
do suporte ao alcance dos objetivos estratgicos associados computao
orientada a servios. Para ele, um nico servio pode fornecer uma coleo de
capacidades. Tais funcionalidades so agrupadas porque se relacionam a um
contexto funcional estabelecido pelo servio.
2.1.2.1 Princpios de design de servios proposto por Thomas Erl
Erl (2009) entende que a chave para ser bem-sucedido na implementao

de uma arquitetura orientada a servios est em compreender o significado de seu
bloco de construo fundamental que o servio.
Para o autor, a orientao a servios um paradigma que abrange um

conjunto especfico de oito princpios de design, onde a unidade mais fundamental
da lgica orientada a servios o servio. (ERL, 2009, p. 25)
Os oito princpios de design de servios identificados pelo autor so:
1. Contrato de servio padronizado
Os servios expressam seu propsito e suas capacidades por meio de um

contrato de servios. Segundo Erl (2009), este seja talvez o componente mais
importante da orientao a servios. No contrato de servio ficam estabelecidos a
natureza e a quantidade de contedo que ser publicado. Inclui tambm a forma
como os servios iro expressar suas funcionalidades, alm de granularidade e
outras questes relacionadas consistncia, confiabilidade e governabilidade.
O autor esclarece ainda que um contrato de servio muito mais do que
uma interface tcnica, como algumas vezes considerado. Um contrato de servios
pode ser composto de um grupo de documentos de descrio dos servios, cada um
dos quais descrevendo uma parte do servio (ERL, 2009, p. 76)
2. Baixo acoplamento de servio
Defende o estabelecimento de um tipo especfico de relacionamento

dentro e fora dos limites do servio, com nfase em reduzir (baixar) as
dependncias entre o contrato do servio, sua implementao e os consumidores do
servio.
Ainda segundo o autor, este princpio permite que o design e a lgica de

um servio possam evoluir independentemente de sua implementao, ao mesmo
tempo em que garante a interoperabilidade bsica com consumidores que se
utilizam das capacidades do servio.
3. Abstrao
Em um nvel fundamental, esse princpio enfatiza a necessidade de

ocultar o maior nmero possvel de detalhes subjacentes de um servio. (ERL,
2009, p. 46)
O princpio da abstrao estabelece que o contrato de servio deve

conter apenas informaes relevantes para o usurio do servio. Detalhes de
implementao e outros, desnecessrios no devem estar presentes no contrato.
O nvel de abstrao do servio precisa ser adequadamente planejado

durante a fase de implementao do servio. Excesso de informao pode induzir ao
uso indevido do servio, resultando em futuros problemas de acoplamento. Falta de
informao poderia trazer prejuzos para sua utilizao e reuso.
Como esse princpio resulta na ocultao deliberada de informaes,

precisamos determinar cuidadosamente que informaes devem ser
expostas. Cada parte dos metadados disponvel pode ser utilizada de um
modo que pode ter consequncias inesperadas no futuro. (ERL, 2009, p.
140)
4. Capacidade de reuso de servio

O autor considera a capacidade de reuso como um dos mais importantes
princpios para alcanar os objetivos da computao orientada a servios, que
tambm uma meta h muito perseguida em vrios modelos de desenvolvimento.
Sob essa perspectiva, talvez no haja outro princpio mais fundamental

para alcanar os objetivos da computao orientada a servios do que o da
capacidade de reuso. (ERL, 2009, p. 148)
No entanto, segundo o autor, o conceito apesar de simples, de difcil

implementao e muitos daqueles que fizeram parte de iniciativas de reuso mal
sucedidas acabaram se desiludindo com essa proposta.
Dentre os principais fatores que contriburam para o fracasso das

iniciativas de implantao de reuso, Erl (2009) destaca:
a) potencial de reuso limitado a ambientes e ou programas proprietrios;

b) componentes projetados com fortes dependncias em outros componentes, via
estruturas de herana, e outras de alto acoplamento;
c) componentes reusveis no eram utilizados o suficiente;
d) componentes reusveis equipados com funcionalidade desnecessrias.
Para o autor, para que um servio alcance a capacidade de reuso, sua

lgica precisa ser implementada da forma mais neutra e agnstica possvel. Ele
estabelece ento o conceito de servio agnstico: Um servio agnstico quando
sua lgica independente dos processos de negcio e da plataforma tecnolgica
proprietria ou de aplicativos proprietrios. (ERL, 2009, p. 155)
Ento, para Erl (2009) um servio ter um bom potencial de reuso se

puder fornecer capacidades que no so especficas a qualquer processo de
negcio e for til automao de mais de um processo de negcio.
5. Autonomia de servio
O princpio da autonomia estabelece a independncia de um servio com

relao ao seu ambiente e outros servios. Para os servios realizarem suas
capacidades de modo consistente e confiante, sua lgica precisa ter um grau de
significativo de controle sobre seu ambiente e recursos. (ERL, 2009, p. 46)
Se houver um programa de software em um estado autnomo em runtime,

esse programa ser capaz de realizar sua lgica independentemente de
influncias externas. Ele, portanto, deve ter o controle para se governar em
runtime. Quanto mais controle o programa tiver sobre o ambiente de
execuo em runtime, mais autonomia poder reivindicar. (ERL, 2009, p.
170)
Maior autonomia ajuda a alcanar maior confiabilidade e previsibilidade

dos programas de software. Por isso, o autor considera a autonomia como uma
considerao-chave de design, sendo um princpio de design que ir suportar o
reuso e a composio de servios.
6. Independncia de estado do servio
O estado refere-se condio atual de alguma coisa. Um avio, por

exemplo, poderia estar em solo ou em voo e esses seriam dois estados possveis
para a aeronave. No caso de servios, poderamos exemplificar os estados ativo e
inativo.
O princpio da independncia de estado estabelece que os servios

agnsticos, para alcanarem seus objetivos de reuso e composio, precisam ser
projetados de forma a consumir o mnimo de recursos computacionais no
processamento de dados referentes ao gerenciamento de seu prprio estado,
delegando, ao mximo essa tarefa.
O gerenciamento de excessivas informaes de estado pode comprometer

a disponibilidade de um servio e minar o seu potencial de capacidade de
escala. Desse modo, os servios so, idealmente, projetados para
manterem informaes de estado apenas quando estas forem necessrias.
(Erl, 2009, p.46).
Segundo Erl (2009), esse princpio enfatiza a necessidade de reduzir ou

eliminar o consumo de recursos de sistema, decorrente de processamento
desnecessrio do gerenciamento de estado.
7. Visibilidade do servio
Uma das questes chave com que o desenvolvedor de software, em uma

arquitetura orientada a servios se depara se as funcionalidades que ele precisa
utilizar j existem ou se precisaro ser implementadas. Isso requer um catlogo de
servios adequadamente construdo, de forma a garantir acesso a informaes
sobre o servio como: seu propsito; suas capacidades e suas limitaes.
Quando um recurso ou servio no est adequadamente visvel,
normalmente os usurios perdem a oportunidade de utiliz-lo e acabam construindo
um recurso prprio, o que acarreta sobreposio funcional ao recurso existente,
introduzindo redundncia na empresa.
Para que os servios sejam posicionados como ativos de TI com ROI

repetvel, eles precisam ser facilmente identificados e entendidos quando
houver oportunidades de reuso. O design de servio, ento, precisa levar
em conta a qualidade de comunicao do servio e suas capacidades
particulares, mesmo que um mecanismo de descoberta (como um registro
de servio) faa parte do ambiente. (Erl, 2009, p.46).
8. Composio de servios
A composio de componentes de software conhecida h muito pelos

desenvolvedores e est no centro do conceito de reuso. Foi implementada por
diversas estratgias e em diversas plataformas como funcionalidades ou bibliotecas
como as de vinculao dinmica (Dynamic Link Library DLL), que popularizou a
composio de software.
Segundo Erl (2009), a orientao a servios fornece uma plataforma de

design segundo a qual a lgica decomposta e recomposta. Assim, servios devem
ser projetados para atuarem como participantes eficazes de uma composio.
A composio pode ser considerada como uma forma de reuso. Mais do

que isso, a composio de servios fornece o meio pelo qual podemos alcanar o
que muitas vezes classificado como o objetivo final da computao orientada a
servios (Erl, 2009, p. 223).
medida que a sofisticao das solues orientadas a servios continua

aumentando, aumenta tambm a complexidade das configuraes de
composio do servio subjacentes. A capacidade de compor efetivamente
os servios um requisito crucial para alcanar alguns dos objetivos mais
fundamentais da computao orientada a servios (Erl, 2009, p.46).
2.1.2.2 Servios, na viso de Josuttis
Josuttis (2008) define servio como uma representao da TI de uma

funcionalidade de negcio independente, atravs de uma interface (bem definida).
Na prtica, normalmente comea a descrever um servio com uma interface
bem definida. Ento, quando determinado consumidor deseja usar o
servio, defina um contrato especfico com base na interface bem definida.
(JOSUTTIS, 2008, p. 25)
Na viso do autor, os atributos que devem ser atendidos na

implementao de servios so:
a. Ser Independente
Servios devem compartilhar apenas tipos de dados fundamentais,

objetivando minimizar as dependncias de tal forma que SOA seja apropriada para
sistemas distribudos com diferentes proprietrios.
b. Granularidade Grossa
Essa recomendao visa compensar a perda de desempenho inerente ao

processamento do servio, quando comparado com o acesso direto aos dados ou a
utilizao de stored procedures. No entanto, Josuttis (2008) ressalta que quando o
preo para processar mais dados fica muito alto, as questes de desempenho
podem levar a servios de granularidade mais refinados. (JOSUTTIS, 2008, p. 140)
c. Visvel / Passvel de Descoberta
Para ser utilizado, um servio precisa ser conhecido e estar visvel.

Quase toda introduo a Web Services introduz trs papeis principais: o de um
fornecedor de servio, o de um consumidor de servio (requisitante) e o de um
broker de servio. (JOSUTTIS, 2008, p. 199)
Josuttis (2008) estabelece tambm uma diferena entre repositrios e

registros. Para ele, repositrios gerenciam servios e seus artefatos de um ponto
de vista de negcio , enquanto que registros gerenciam servios do ponto de vista
tcnico. (JOSUTTIS, 2008, p. 200)
Repositrios gerenciam interfaces, contratos, SLAs, dependncias, etc, e

devem ser independentes da infraestrutura do servio.
d. Sem Estado
Um servio sem estado quando todas as variveis e dados da instncia

do servio so descartados aps a sua execuo. Observe que estamos falando
sobre os dados do servio em si, o que no nem o processo nem a aplicao que
est chamando o servio. (JOSUTTIS, 2008, p. 165)
e. Idempotente
Idempotncia a habilidade de refazer uma operao caso no tenha

certeza que a mesma foi completada (JOSUTTIS, 2008, p.29).
f. Reutilizvel
Idealmente, cada funcionalidade deveria ser implementada apenas uma

vez. Assim, todos os sistemas que necessitam de uma certa funcionalidade apenas
chamariam o mesmo servio. Segundo o autor, o reuso pode, no entanto, incorrer
em problemas de performance. [..] a reusabilidade pode ser um objetivo, mas no
uma regra (JOSUTTIS, 2008, p.29).
g. Composto
Servios podem usar/chamar outros servios. Sendo assim, as

funcionalidades de negcio maiores podem ser quebradas em passos menores, que
por sua vez tambm so servios.
Os servios, na viso do autor, devem ainda apresentar as seguintes

caractersticas:
1. Alta Interoperabilidade
O objetivo da interoperabilidade poder conectar facilmente sistemas

heterogneos. Segundo Josuttis (2008), a idia no nova e, antes de SOA, era
apresentada pelo conceito de EAI (enterprise application integration, ou integrao
de aplicaes corporativas).
Para SOA, no entanto, a alta interoperabilidade o comeo e no o fim.

Isso a base a partir da qual comeamos a implementar as funcionalidades
de negcio (servios) e que espalhada pelos mltiplos sistemas
distribudos. (JOSUTTIS, 2008, p.16).
2. Acoplamento fraco
Segundo Josuttis (2008), o acoplamento fraco a chave para que os

sistemas alcancem trs importantes objetivos: flexibilidade; escalabilidade e
tolerncia a falhas.
Acoplamento fraco um conceito de minimizar as dependncias.
Quando as dependncias esto minimizadas, as modificaes tm os efeitos
minimizados e os sistemas ainda executam quando partes deles esto quebradas ou
indisponveis. (JOSUTTIS,2008,p.16).
2.1.3 Comparando os modelos de implementao de Erl e Josuttis
Os conceitos tcnicos chave de Josuttis (2008) se equivalem aos

princpios de design propostos por Erl (2009) e resumem os principais conceitos e
objetivos descritos pela maioria dos autores pesquisados para descrever uma
arquitetura orientada a servios, do ponto de vista da arquitetura de software.
O quadro abaixo apresenta uma comparao entre os conceitos

apresentados pelos dois autores para a conceituao de servios.
Erl Josuttis
Contrato de Grupo de documentos (visvel) Passvel Registros completos,

servio que descrevem o servio de descoberta incluindo SLAs
Baixo Reduzir as dependncias Acoplamento Minimizar
acoplamento entre contrato, fraco dependncias
implementao e
utilizao
Abstrao O contrato deve fornecer Independente Utiliza apenas dados
apenas informaes fundamentais e no
relevantes para a depende de outros
utilizao do servio servios.
Reuso Talvez a mais importante Reuso Deve ser um objetivo,
caracterstica mas no uma regra
Autonomia Independncia em relao Interoperabilidade Pode conectar
ao ambiente e a outros sistemas
servios heterogneos
Independncia Reduzir o processamento Sem estado Todas as variveis da
de estado desnecessrio para instncia so
gerenciamento de estado descartadas aps a
sua execuo
Visibilidade Incentiva o uso e o reuso Visvel (Passvel Acesso facilitado
de descoberta)
Composio Forma otimizada de reuso Composto Servios podem
usar/chamar outros
servios
Granularidade Visa compensar a
grossa perda de desempenho
inerente ao
processamento do
servio
Idempotncia habilidade de refazer
uma operao
Tabela 1 - Comparativo de princpios de orientao a servios
2.1.4 Arquitetura Orientada a Servios
No trabalho de Keen (2004), SOA definida como uma abordagem para

integrao de arquiteturas baseadas no conceito de servio. Para ele, SOA uma
arquitetura que aplica conceitos que foram utilizados com sucesso em
implementaes de desenvolvimento orientado a objetos, desenho baseado em
componentes e tecnologias de EAI Enterprise Application Integration, Integrao
de aplicaes corporativas. (KEEN, ACHARYA, et al., 2004)
Para Mller (MLLER, HAN, et al., 2009) SOA um conjunto de

princpios e melhores prticas para implementao e execuo de processos de
negcio automatizados em ambientes de TI heterogneos.
Segundo Erl (2009), uma implementao SOA pode consistir em uma

combinao de tecnologias, produtos, APIs, extenses da infraestrutura de suporte
e vrias outras partes. A implementao da arquitetura orientada a servios, em
cada empresa, exclusiva; contudo, ela caracterizada pela introduo de novas
tecnologias e plataformas que suportam especificamente a criao, a execuo e a
evoluo das solues orientadas a servios.
Bieberstein (2008) apresenta SOA como uma forma de aproximar a

linguagem do negcio e da TI. Para ele, o conceito de servio um caminho natural
para compreender a empresa e o negcio. Negcio um conjunto de servios de
negcio organizados em um fluxo de trabalho para realizar um processo de negcio
que realiza o que precisa ser realizado. disso que SOA trata. SOA no
tecnologia, SOA negcio. (BIEBERSTEIN, LAIRD, et al., 2008, p. 10)
De forma semelhante a Biebertein (2008), High (2005) afirma que o

objetivo principal de SOA alinhar o mundo dos negcios com o mundo da TI,
tornando ambos mais efetivos. (HIGH, KINDER e GRAHAM, 2005, p. 6)
2.1.5 OASIS e o Modelo de Referncia SOA.
A OASIS (Organizao para o Avano de Padres de Informao

Estruturada) www.oasis-open.org - um consrcio sem fins lucrativos que
impulsiona o desenvolvimento, convergncia e adoo de padres abertos para a
sociedade da informao global. Segundo o sitio da organizao, ela promove o
consenso da indstria e produz padres mundiais a respeito de temas diversos,
incluindo SOA.
O consrcio tem mais de 5.000 participantes, representando mais de 600

organizaes, incluindo os mais importantes representantes do mercado de
tecnologia de TI, como IBM, Microsoft, Oracle, Adobe, HP, Red Hat, Novell, s para
citar alguns, alm de membros individuais em 100 pases.
Em 2005 a OASIS publicou o Modelo de Referncia SOA - OASIS SOA-

RM TC, com o objetivo de incentivar o crescimento contnuo de implementaes
especficas e diferentes de SOA, preservando uma camada comum que pode ser
partilhada e compreendida entre aquelas ou futuras implementaes .
A OASIS (MACKENZIE, LASKEY, et al., 2006) define Service Oriented

Architecture (SOA) como um paradigma para organizao e utilizao de
capacidades distribudas que podem estar sob o controle de diferentes domnios
proprietrios.
SOA um meio de organizar as solues que promove o crescimento,

reutilizao e interoperabilidade. No em si uma soluo para os
problemas de domnio, mas sim um paradigma de organizao e entrega
que os capacita a obter mais valor de uso tanto de capacidades que so
localmente "propriedade" e aqueles sob o controle dos outros. Ele tambm
permite um para expressar solues de uma forma que torna mais fcil
modificar ou evoluir a soluo identificada ou tentar solues alternativas.
SOA no fornece quaisquer elementos de domnio de uma soluo que no
existem sem SOA. (MACKENZIE, LASKEY, et al., 2006)
O modelo de referncias baseia-se na definio dos principais conceitos

da arquitetura e a relao entre eles, tendo o servio como elemento central.
Figura 1 - Principais conceitos do Modelo de Referncia
Servio Um mecanismo que habilita o acesso a uma ou mais

capacidades
Visibilidade o que habilita a interao entre o servio oferecido e

seu consumidor.
O modelo prev trs condies para a visibilidade:
conscincia, concordncia e acessibilidade.
Conscincia A conscincia do servio requer

que a descrio do servio e
poltica ou pelo menos um
subconjunto adequado estejam
disponveis de tal maneira que,
direta ou indiretamente, um
consumidor potencial esteja ciente
da existncia e das competncias
do servio.
Concordncia Refere-se concordncia entre

(boa-vontade, fornecedor e consumidor para
cooperao) interagir, com base em polticas
de fornecimento e utilizao do
servio acordadas.
Acessibilidade Os participantes do servio

precisam estar aptos a interagir.
Se um servio no acessvel ele
no estar efetivamente visvel.
Interao Envolve a execuo de aes na direo do servio.

Geralmente realizada na forma de mensagens, mas
pode tambm ocorrer a partir de mudanas de estado
de um recurso compartilhado.
Dois conceitos chave esto envolvidos na interao.
So eles: o modelo de informao e o modelo de
comportamento
Modelo de Informao que pode ser trocada

Informao com o servio.
Modelo de o conhecimento das aes

Comportamento envolvidas no servio e no
processo ou aspectos temporais
de uma interao com o servio.
Exemplo: autorizao para acesso
a dados em um servio de
alterao em um SGBD.
Efeito no mundo real Refere-se ao propsito particular relacionado com a

interao com um servio. Uma solicitao de reserva
em um voo, por exemplo, muda o estado da reserva e
um dos requisitos para habilitar uma pessoa a
embarcar em uma aeronave. O usurio no conhece
os detalhes de implementao e o servio no sabe
se a reserva foi realizada pelo prprio interessado ou
algum em seu nome, mas o servio tem efeito sobre
o estado da reserva e na habilitao do passageiro.
Descrio do Servio O propsito da descrio facilitar a interao e a

visibilidade do servio.
Em geral, deve possuir os seguintes itens de
informaes:
1. Que o servio existe e est acessvel
(acessibilidade) ;
2. Que o servio executa certa funo ou conjunto de
funes (funcionalidades);
3. Que o servio opera sob um conjunto especfico de
restries e polticas;
4. Que o servio ir (para alguma extenso implcita
ou explicita) concordar com as polticas como
prescritas pelo consumidor do servio (polticas);
5. Como interagir com o servio de forma a alcanar
os objetivos desejados, incluindo o formato e
contedo da informao trocada entre o servio e o
consumidor e as sequncias de informaes trocadas
que podem ser esperadas (interface).
Polticas e Contratos Uma poltica representa alguma restrio ou condio

sobre o uso, distribuio ou descrio de uma
entidade.
Um contrato, por outro lado, representa um acordo de
duas ou mais partes.
Polticas potencialmente se aplicam a muitos aspectos
do SOA: segurana, privacidade, Qualidade de
Servio e assim por diante. Alm dessas polticas
orientadas a infraestrutura, os participantes PODEM
tambm expressar as polticas orientadas a negcios
tais como as horas de negcios, polticas retornadas
e assim por diante.
natural que a descrio do servio contenha
referncias s polticas associadas com o servio.
Assim como as polticas, os contratos podem cobrir
uma ampla faixa de aspectos de servios: acordos de
qualidade de servio, acordos de interface e
coreografia e acordos comerciais.
Contexto de Execuo o conjunto de elementos de infraestrutura, entidades

processo, afirmaes e acordos de polticas que so
identificados como parte de uma interao de servio
instanciado, e ento forma um caminho entre aqueles
com necessidades e aqueles com competncias.
O consumidor e o provedor podem ser visualizados
como locais separados em um mapa e, para um
servio ser realmente invocado, um caminho precisa
ser estabelecido entre estes dois locais. Este caminho
o contexto de execuo.
Tabela 2 - Quadro resumo do Modelo de Referncia SOA
O modelo de referncia prope ainda um guia para estabelecer a

conformidade com a arquitetura SOA, indicando que as seguintes caractersticas
devem estar presentes:
a) Ter entidades que podem ser identificadas como servios como definido no
Modelo de Referncia;
b) Estar apta a identificar como a visibilidade estabelecida entre os provedores e
consumidores de servio;
c) Estar apta a identificar como a interao ser mediada;
d) Estar apta a identificar como os efeitos do uso de servios so compreendidos;
e) Ter descries associadas com servios;
f) Estar apta a identificar o contexto de execuo requerido para suportar
interaes; e
g) Ser possvel identificar como as polticas so tratadas e como os contratos
podem ser modelados e formatados.
2.1.6 Josuttis (2008) e os ingredientes chave de SOA
Em sua definio de SOA, Josuttis (2008) estabelece ainda duas

abordagens que merecem destaque. So elas: conceitos tcnicos-chave e
ingredientes-de SOA.
2.1.6.1 Conceitos tcnicos-chave
Os principais conceitos tcnicos de SOA, sugeridos por Josuttis (2008),

que permitem lidar com as caractersticas de sistemas so: Servios;
Interoperabilidade; Acoplamento fraco.
2.1.6.2 Ingredientes de SOA
O autor argumenta que tudo o que se precisa para habilitar SOA, no que
se refere aos conceitos, introduzir servios, interoperabilidade e acoplamento fraco
(conceitos tcnicos chave).
No entanto, ele lembra que no se pode comprar SOA. Por isso, esses
conceitos precisam ser introduzidos de forma apropriada, encontrando o nvel certo
de centralizao e o ajuste dos processos correspondentes.
Josuttis (2008) apresenta quatro ingredientes chave para uma

implantao bem sucedida de SOA: infra-estrutura; arquitetura; processos;
governana.
Infra-estrutura a parte tcnica de SOA que possibilita a interoperabilidade.

Josuttis (2008) define o Barramento Corporativo de Servios
(ESB) como a infraestrutura de um cenrio SOA, que possibilita
que sistemas heterogneos faam chamadas a servios.
Suas responsabilidades incluem transformao de dados,
roteamento, segurana, confiabilidade, monitoramento e
logging. .
Arquitetura Responsvel por restringir todas as possibilidades de SOA, para
obter um sistema funcional e de fcil manuteno.
So de responsabilidade das decises de arquitetura:
a) Classificar os diferentes tipos de servios;
b) Decidir a respeito da quantidade de acoplamento fraco;
c) Definir as polticas, regras e padres, esclarecer os
papis e responsabilidades, tecnologia, infraestrutura,
padres e assim por diante.
Processos Refere-se criao de processos apropriados para que as
solues possam evoluir adequadamente dos requisitos
produo.
Podem incluir metodologias de modelagem de processos
corporativos como o BPM.
Governana o metaprocesso de todos os processos, e a estratgia de
SOA.
Inclui encontrar pessoas certas que sejam capazes de combinar
todos os diferentes ingredientes de SOA para criar um resultado
que funcione e que seja apropriado.
Tabela 3 - Ingredientes SOA - (JOSUTTIS, 2008)
A falta destes ingredientes o problema mais comum que encontro nos

projetos reais de SOA. Para estabelecer SOA com sucesso, preocupe-se
com sua infra-estrutura, arquitetura e processos (incluindo metaprocessos,
governana). (JOSUTTIS, 2008, p. 17)
Josuttis (2008) considera longo o caminho entre a idia incial de negcio

ou requisito at a sua implementao rodando em um ambiente de produo. Como
normalmente o controle no est nas mos de uma pessoa ou mesmo de um
pequeno grupo de pessoas, ser necessria a criao de processos apropriados
que incluem modelagem de processos corporativos (BPM) e desenvolvimento de
software orientado a modelos (MDSD Model-driven software development).
Nesse contexto, High (2005) apresenta um ciclo continuo para a

arquitetura SOA, que organizado em quatro estgios: modelagem; construo;
instalao e gerenciamento, conforme apresentado na tabela abaixo:
Estgios do ciclo de Componentes

vida de SOA
Capturar os requisitos do negcio e seus objetivos.

Traduzir esses requisitos em processos de negcio
Modelagem modelados.
Analisar os modelos buscando o seu aperfeioamento,
estabelecer indicadores.
Integrar pessoas (analistas de negcios, de processos,
desenvolvedores)
Construo
Integrar processos e servios
Integrar e gerenciar informaes
Estgios do ciclo de Componentes
vida de SOA
Descoberta
Instalao Construo e teste
Composio
Gerenciar aplicaes e servios
Gerenciamento Gerenciar identidade e conformidade
Monitorar mtricas de negcio
Tabela 4 - Estgios do ciclo de vida SOA (HIGH, KINDER e GRAHAM, 2005)
2.1.7 Os Fundamentos para a arquitetura SOA OASIS Julho/2011.
Em julho de 2011 a OASIS lanou a verso 1.0 do Reference Architecture

Foundation for Service Oriented Architecture Fundamentos de Referncia de
Arquitetura para Arquitetura Orientada a Servios. (BROWN, ESTEFAN, et al., 2011)
Enquanto o Modelo de Referncia SOA SOA-RM trata as questes de

forma abstrata (o qu), o foco dos Fundamentos da Arquitetura de Referncia
SOA-RAF, no como, de forma concreta, uma arquitetura SOA pode ser construda.
A viso da SOA-RAF do paradigma de arquitetura SOA parte de uma

perspectiva de ecossistemas. Um ecosistema SOA um espao em que pessoas,
processos e mquinas de atuam em conjunto para entregar capacidades como
servios.
Visualizado como um todo, um ecossistema SOA uma rede de

processos discretos e mquinas que, juntamente com uma comunidade de pessoas,
cria, usa e governa servios especficos, bem como fornecedores externos de
recursos necessrios para aqueles servios.
Os fundamentos da arquitetura SOA propostos pela OASIS (BROWN,

ESTEFAN, et al., 2011), descrevem exaustivamente modelos completos de
implementao para o repositrio e demais componentes da arquitetura. A
apresentao e anlise desses modelos extrapolam o escopo deste trabalho, mas
precisam ser avaliados como parte das atividades tcnicas no projeto de
implantao da arquitetura SOA.
2.2 GOVERNANA DE TI E GOVERNANA DE SOA
At aqui, procuramos estabelecer alguns dos principais conceitos

referentes a SOA e Servios, suas caractersticas e princpios de design. No
entanto, um projeto para implantao de SOA uma deciso de arquitetura que
precisa ser compreendido e planejado considerando-se aspectos de Governana.
Como j apresentamos, SOA no apenas tecnologia, mas principalmente Negcio.
Brown (BROWN, ESTEFAN, et al., 2011) define Governana Corporativa

como um conjunto dos direitos decisrios e dos indicadores (mtricas) e polticas
que permitem o acompanhamento que asseguram o cumprimento dessas decises
e Governana de Ti como uma estrutura de relacionamentos e processos para
direo e controle da empresa.
Governana de TI um subconjunto da governana corporativa, que trata

da gesto e controle de ativos de TI, pessoas, processos e infraestruturas,
bem como a maneira pela que os ativos so geridos e adquiridos.
(BROWN, ESTEFAN, et al., 2011, p. 4)
Para Weill (WEILL e ROSS, 2006), Governana de TI a especificao

dos direitos decisrios e do framework de responsabilidades para estimular
comportamentos desejveis na utilizao da TI.
Seundo Weill (2006), uma Governana de TI eficaz deve tratar de trs

questes:
1. Quais decises devem ser tomadas para garantir a gesto e o uso

eficazes de TI?
2. Quem deve tomar essas decises?
3. Como essas decises sero tomadas e monitoradas?
Weill (2006) relaciona cinco decises que agrupam o que ele definiu como
questes essenciais para deciso de TI, que apresentamos no quadro abaixo:
Decises de TI Questes Essenciais
Qual modelo operacional da empresa?

Qual o papel da TI no negcio?
Princpios de TI
Quais so os comportamentos desejveis em termos de
TI?
Como a TI ser custeada?
Quais so os processos centrais de negcio da

empresa? Como eles se relacionam?
Quais informaes determinam esses processos
centrais? Como os dados devem ser integrados?
Quais capacidades tcnicas devem ser padronizadas na
Arquitetura de TI empresa toda para suportar as eficincias de TI e
facilitar a padronizao e a integrao dos processos?
Quais atividades devem ser padronizadas na empresa
toda para dar suporte integrao dos dados?
Quais opes tecnolgicas guiaro a abordagem da
empresa para as iniciativas de TI?
Quais servios de infraestrutura so mais crticos para
que se atinjam os objetivos estratgicos da empresa?
Para cada cluster de capacidade, que servios da
infraestrutura devem ser implementados na empresa
toda e quais os requisitos de nvel de servio desses
Infraestrutura de TI servios?
Como os servios de infraestrutura devem ser
apreados?
Qual o plano para manter atualizadas as tecnologias de
suporte?
Que servios de infraestrutura devem ser terceirizados?
Quais as oportunidades de mercado e de processos de
negcio para novas aplicaes comerciais?
Como os experimentos so concebidos de modo que
estimem o seu sucesso?
Necessidades de Como as necessidades de negcio podem ser
aplicaes de negcio satisfeitas dentro dos padres da arquitetura de TI?
Quando uma necessidade de negcio justifica uma
exceo s normas?
Quem ser detentor dos resultados de cada projeto e
instituir mudanas organizacionais para garantir a
gerao de valor?
Que mudanas ou melhorias de processos so
Investimentos e estrategicamente mais importantes para a empresa?
priorizao de TI Quais so as distribuies nos portflios atual e
proposto de TI? Esses portflios so consistentes com
os objetivos estratgicos da empresa?
Qual a importncia relativa de investimentos na

empresa como um todo versus investimentos nas
unidades de negcio? As prticas reais de
investimentos refletem essa importncia relativa?
Tabela 5 Questes essenciais para deciso de TI - (WEILL e ROSS, 2006)
Para Brown (2006), Governana de SOA uma extenso da governana

de TI voltada para o ciclo de vida de servios, metadados e aplicativos compostos
em uma organizao de arquitetura orientada a servios.
Governana SOA define as mudanas na governana de TI para garantir

que os conceitos e princpios de orientao a servios e sua arquitetura
distribuda sejam gerenciados adequadamente e sejam capazes de cumprir
os objetivos de negcio declarados para os servios. (BROWN, ESTEFAN,
et al., 2011, p. 5)
Ainda para o autor, SOA uma abordagem para a arquitetura distribuda

que cruza as linhas de negcios e de TI (BROWN, ESTEFAN, et al., 2011, p. 5),
indicando assim uma maior necessidade de efetiva governana SOA. Alm disso,
Governana de SOA fornece uma estrutura para a reutilizao e compartilhamento
de servios, um valor chave para alavancar SOA.
Brown (2006) acrescenta que a governana de SOA estende a

governana de TI para estabelecer direitos decisrios, polticas de servios,
processos e ciclo de vida de SOA para resolver preocupaes como:
1. Registro do servio
2. Versionamento do servio
3. Propriedade do servio
4. Financiamento do servio
5. Monitoramento do servio
6. Auditoria do servio
7. Diagnstico do servio
8. Identificao do servio
9. Modelagem do servio
10. Publicao do servio
11. Descoberta do servio
12. Desenvolvimento do servio
13. Utilizao do servio
14. Provisionamento do servio
15. Acesso ao servio
16. Implantao de servios e aplicaes que agrupam servios
17. Segurana de servios
2.2.1 O Centro de Competncia SOA - CCS
Erl (2009), afirma que necessria uma estrutura de governana especial

para SOA, que pode introduzir novos recursos, papis, processos e at mesmo
novos grupos ou departamentos. O processo de mudana para esse novo modelo
de governana pode desafiar abordagens tradicionais e exigir tempo, despesas e
muita pacincia.
Bieberstein (2008) afirma que a Governana SOA tem foco nos servios
que existem ou precisam ser criados para a realizao de uma Arquitetura Orientada
a Servios.
Ainda segundo o autor, se existir um grupo na organizao que seja

responsvel pela viso estratgica e ttica, ela ser uma boa interface entre o
negcio e a TI. Esse grupo poder tambm assumir responsabilidades de
governana SOA. (BIEBERSTEIN, LAIRD, et al., 2008, p. 32)
Para ele, as principais atribuies desse grupo seriam:
a) Governar e atuar junto aos grupos de TI e do Negcio, com base na

SOA;
b) Atuar nas questes de Governana e no na implementao de SOA
c) Liderar a criao e implantao dos princpios, polticas e
procedimentos da Governana SOA;
d) Governar as estratgias, tticas e procedimentos operacionais da
SOA;
e) Governar o ciclo de vida SOA;
f) Monitorar a vitalidade do programa SOA, fazendo ajustes,
desenvolvendo habilidades, identificando novos papis e mudanas,
incentivar as mudanas necessrias para ampliar a maturidade do
programa SOA e a agilidade da organizao.
O autor defende ainda que esse grupo, que ele denomina CdE Centro
de Excelncia SOA (CoE, na verso original em ingls) precisa ainda ser dirigido
por um comit que inclua representantes de todas as partes interessadas, como
reas de desenvolvimento, escritrio corporativo de projetos e demais reas de
negcio. Esse comit deve ser liderado por um executivo responsvel pelos esforos
em SOA e que dever atuar em conjunto com o CIO, com a diretoria e com os
demais lderes da organizao, tendo tambm um bom trnsito entre o negcio e a
TI.
Josuttis (2008) tambm se refere, de forma muito semelhante, a essa

estrutura que ele denominou Centro de Competncia SOA, responsvel por
coordenar, padronizar, consolidar e controlar toda a estratgia de implantao de
SOA. Para ele, o CCS deve ser uma equipe virtual formada de dirigentes,
desenvolvedores e especialistas de TI que precisam dispor de tempo e recursos
suficiente para desenvolver a sua tarefa de implantao e governana SOA.
(JOSUTTIS, 2008, p. 228)
2.2.2 Papis e responsabilidades SOA
Bieberstein (2008) enumera os papis e responsabilidades que precisam

ser considerados, como ponto de partida, para uma implementao de SOA.
Segundo o autor, a implementao desses papis precisa ser avaliada segundo a
disponibilidade e o tamanho do esforo na implementao. Nem todos os papis
precisam ser implementados, mas eles precisam ser ao menos avaliados, aceitos,
rejeitados ou adaptados, lembrando que uma pessoa pode assumir mais de um
papel. (BIEBERSTEIN, LAIRD, et al., 2008, p. 34)
Papel Responsabilidade
Lider do CdE SOA. Precisa assegurar que as atividades de SOA esto

ocorrendo, embora usualmente no seja ele quem as
(trataremos em nosso
executa.
projeto como CCS)
responsvel por governar SOA na organizao
liderando a criao dos princpios, polticas e
procedimentos que garantem a SOA.
Arquitetos de Servios So peritos em tecnologia de servios. Sua
responsabilidade transferir conhecimento sobre
tecnologias de servios e orientar os projetos para os
padres SOA.
Service Designers So arquitetos responsveis pela criao de servios
completos e consistentes. Inicialmente eles podero ser
lotados no CdE, mas devero, passadas as etapas de
implantao da SOA, compor os departamentos.
Desenvolvedor do o engenheiro de software responsvel pela
implementao do servio seguindo as especificaes
Servio
do Service Designer.
Engenheiro de testes Responsvel pelo planejamento e execuo de testes
do servio incluindo requisitos funcionais e no
funcionais.
Arquivista de Servios Trabalha em parceria com os arquitetos e
desenvolvedores para manter os registros dos servios.
Especialista em Trabalha no dia-a-dia da governana SOA, validando
polticas e procedimentos e monitorando a vitalidade da
Governana SOA
arquitetura. Sem esse papel os esforos de implantao
tendem a diminuir em pouco tempo.
Lder de Servios de Apoia e incentiva a anlise e criao de servios de
negcio. Geralmente uma pessoa do negcio com
Negcios
bons conhecimentos de TI ou uma pessoa de TI com
bom conhecimento do negcio.
Analista de Processos Responsvel pela modelagem e aperfeioamento de
processos de negcio. Atua tanto sobre processos
de Negcio
existentes quanto na criao de novos processos.
Desenvolvedor de Responsvel pela criao de processos executveis
baseados nos modelos de processos de negcio.
Processos de Negcio
Tabela 6- Papis e Responsabilidades propostos por Bieberstein (2006) para implementao

de SOA
2.2.3 Polticas SOA
Na viso de Josuttis (2008), polticas SOA so regras e guias necessrios

para estabelecer e vivenciar SOA. Essas polticas definem o que correto tanto do
ponto de vista tcnico como do ponto de vista organizacional. (JOSUTTIS, 2008, p.
235)
Polticas devem ser definidas para diferentes tpicos ou assuntos. Josuttis
(2008) exemplifica a adoo de polticas como uma tabela ou quadro conforme
apresentado em seguida:
Assunto Poltica Obriga Infra-estrutura Fornecedor Consumidor

trio
Privacida DMZ. Consumidores Sim Fornece auditoria No Tem que

de devem garantir que (monitoramento) responsvel garantir que as
nenhum uso errado chamadas de
seja possvel servio e/ou
resultados do
processamento
sejam permitidos
MEPs Apenas os padres Sim Fornece APIs Tem que Tem que usar a
requisio/resposta apenas para especificar API
sncrono e esses dois MEPs MEP para correspondente
publicar/assinar cada servio
assncronas so
permitidos
Tabela 7- Exemplo de um formato para formulao de polticasSOA (JOSUTTIS, 2008, p. 237)
2.3 SOA NA ORGANIZAO E O PAPEL DA TI
Um plano de implantao de SOA pode se deparar com vrios problemas

tcnicos, culturais, organizacionais e estruturais que precisam ser analisados de
forma cuidadosa.
Enquanto os processos distribudos so uma realidade hoje, os sistemas

e as empresas so frequentemente estruturados de tal forma que no suportam
distribuio. (JOSUTTIS, 2008, p. 89)
As empresas geralmente so organizadas em departamentos que

possuem, normalmente, suas prprias aplicaes ou sistemas especficos.
Para Josuttis (2008), colaborao um requisito-chave para SOA. Desde

a formulao de uma ideia at a manuteno de sua realizao, os sistemas
distribudos requerem a colaborao. Mas claro que a colaborao difcil nas
organizaes que consistem de departamento que se comportam como territrios
isolados. Nestes casos, mudar a cultura da empresa ser o fator-chave para o
sucesso de SOA (JOSUTTIS, 2008, p. 91). Para ele, CEO e CIO devem
compreender o impacto que SOA ter em suas organizaes.
Alm das questes organizacionais, algumas outras, ligadas
principalmente cultura do prprio departamento de TI precisam ser consideradas.
Para Erl (2009), a maioria das solues foram criada numa abordagem
que consiste em identificar as tarefas de negcio a serem automatizadas, especificar
os requisitos de negcio e construir a lgica correspondente.
Nessa abordagem, quando surgem novos requisitos e processos ou

modificaes significativas so necessrias, a equipe de TI, que normalmente est
anexada aos sistemas desenvolvidos, precisa construir um aplicativo inteiramente
novo.
Nesse ltimo caso, embora construir aplicativos descartveis

repetidamente no seja a abordagem perfeita, mostrou-se um meio legtimo
de automatizar o negcio. (ERL, 2009, p. 48)
Essa ainda uma abordagem muito popular que traz, segundo Erl (2009),
os seguintes aspectos positivos.
As solues podem ser construdas Porque s precisam se preocupar em

atender a um conjunto restrito de
de forma eficiente
requisitos associados a um conjunto
limitado de processos de negcio.
Menor esforo de anlise Porque os analistas se concentram em
apenas um processo por vez e, desse
modo, s se preocupam com as
entidades de negcios e domnios
associados a esse nico processo
Simplificao do design e da Porque os designs de solues so
centrados em um ponto de vista ttico. O
arquitetura da soluo.
nico propsito de cada design
automatizar apenas um ou um conjunto
especfico de processos de negcio
Ciclo de vida do projeto
de Porque o escopo de entrega bem
definido e geralmente no muda.
desenvolvimento de cada soluo
simplificado e relativamente previsvel
Construir novos sistemas a partir do As organizaes que constroem

repetidamente aplicativos descartveis
zero permite que as organizaes
podem se beneficiar das ltimas
aproveitem os ltimos avanos inovaes tecnolgicas a cada novo
projeto.
tecnolgicos
Tabela 8 - Vantagens do modelo de desenvolvimento tradicional (ERL, 2009)

claro que todas essas caractersticas, e a cultura normalmente vigente
dificultam a introduo de um novo paradigma de orientao a servios.
No entanto, algumas importantes desvantagens do modelo tradicional so

tambm listadas por Erl (2009).
No to eficiente quanto parece O foco ttico na entrega das solues de

requisitos de processo especficos torna
o escopo de projetos em
desenvolvimento muito visado.
O processo seria mais eficiente se se a
criao da lgica redundante pudesse
ser evitada.
Pode gerar um enorme desperdcio A criao de uma lgica nova em uma
dada empresa resulta, em geral, numa
quantidade significativa de
funcionalidades redundantes.
Sobrecarrega a empresa Cada aplicativo novo ou ampliado se
soma ao inventrio de TI. Necessidades
de manuteno e exigncias de
manuteno podem inchar um
departamento de TI a ponto de tornar-se
um peso significativo para a organizao
como um todo.
Pode resultar em infra-estruturas Ter de hospedar numerosos aplicativos
desenvolvidos com base em diferentes
complexas e arquiteturas
geraes tecnolgicas e, talvez, at
corporativas complicadas mesmo em diferentes plataformas
tecnolgicas, exige, muitas vezes, que
cada plataforma tenha requisitos
arquitetnicos nicos.
A integrao torna-se um desafio Aplicativos desenvolvidos tendo-se em
mente apenas a automao de
constante
processos de negcio especficos, em
geral, no so projetados para acomodar
outros requisitos de interoperabilidade.
Tabela 9 - - Desvantagens do desenvolvimento de sistemas tradicional (ERL, 2009)
Em uma soluo orientada a servios as funcionalidades no so mais

especficas a nenhum aplicativo ou processo de negcio especfico. Por isso so
classificados como ativos de TI agnsticos e reusveis.
Erl (2009) afirma que depois das repetidas geraes de solues

distribudas tradicionais, a gravidade dos problemas foi ampliada. O modelo
orientado a servios representa um estado evolutivo importante na histria da TI,
porque combina elementos de design bem-sucedidos de abordagens antigas com
novos elementos de design, que tiram proveito da inovao conceitual tecnolgica.
O desafio aqui parece estar na mudana cultural necessria para que

tanto a organizao como um todo quanto a diviso de TI estejam prontos para a
adoo do novo paradigma de orientao a servios.
2.4 MATURIDADE DA ARQUITETURA DE TI
Em 2006 Jeanne W. Ross, em parceria com Peter Weill e David C.

Robertson publicaram o Arquitetura de TI como Estratgia Empresarial, com base
em uma srie de projetos de pesquisa que exploraram a arquitetura empresarial de
mais de 200 empresas entre 1995 e 2005.
Ross (2006) define a Arquitetura empresarial como a lgica organizadora

para processos de negcios e a infraestrutura de TI que reflete os requisitos de
integrao e padronizao do modelo operacional da empresa.
Segundo os autores, a unidade de TI lida tipicamente com quatro nveis

arquitetnicos abaixo da arquitetura empresarial:
Processos centrais de Conjunto estvel de capacidades gerais de que a

empresa precisa para executar seu modelo
negcios
operacional e responder a oportunidades de
mercado.
Dados compartilhados dos Podem ser arquivos da clientela compartilhados
pelas linhas de produtos ou dados sobre itens e
processos centrais
fornecedores principais, etc.
Principais tecnologias de Tecnologia de software que permite a integrao
de aplicaes e o acesso a dados compartilhados.
automao e vinculao
Podem ser Grandes pacotes de software , como
sistemas de ERP, portais de acesso padronizado a
sistemas e dados, etc.
Principais clientes Maiores grupos de clientes atendidos pelo alicerce
de execuo.
Tabela 10 - Os quatro nveis arquitetnicos propostos por Ross (2006)
Ross (2006) identificou quatro estgios de maturidade de arquitetura,
conforme apresentamos no quadro abaixo:
1 Silos de Negcio As empresas concentram seus investimentos em

solues para problemas e oportunidades locais de
negcio.
As aplicaes alinham-se com as estruturas setoriais.
Tais solues isoladas, criam um legado de sistemas
incapazes de se comunicar entre si.
Na pesquisa, apenas 12% das empresas permaneciam
nesse estgio.
2 Tecnologia As empresas transferem parte de seus investimentos
de TI das aplicaes locais para a infraestrutura
Padronizada
compartilhada.
Assim como no estgio de Silos de Negcio, o papel
da TI, nesse estgio, padronizar os processos locais
de negcios.
As empresas desse estgio usualmente aumentam o
acesso a dados compartilhados introduzindo sistemas
de armazenamento, mas os dados de transaes
continuam embutidos em aplicaes individuais.
48% das empresas pesquisadas se encontravam
nesse estgio.
3 Ncleo Otimizado As empresas passam de uma viso local de dados e
aplicaes para uma viso empresarial.
So eliminadas as redundncias de dados.
Nesse estgio, as empresas esto desenvolvendo
interfaces para dados corporativos crticos.
Os investimentos de TI passam de aplicaes locais e
infraestrutura compartilhada para sistemas
empresariais e dados compartilhados.
A TI assume o papel de promover a realizao dos
objetivos da empresa construindo plataformas para
dados e processos de negcio reutilizveis.
34% das empresas pesquisadas se encontravam
nesse estgio.
4 Modularidade dos Possibilita a agilidade estratgica por meio de mdulos
customizados ou reutilizveis.
Negcios
A administrao refina e cada vez mais modulariza os
processos que foram digitalizados no estgio de
Ncleo Otimizado.
Podem ser criados mdulos reutilizveis, permitindo
que as unidades comerciais selecionem em um menu
de opes, processos voltados para o cliente.
Por meio web services, por exemplo, as empresas
podem criar servios comerciais reutilizveis.
Podem alternativamente conferir aos gerentes das
unidades comerciais maior poder sobre o projeto de
processos de front-end, que eles podem criar
individualmente ou comprar como mdulos que se
conectam com os dados centrais e com processos de
back-end.
Apenas 6% das empresas pesquisadas se
encontravam nesse estgio.
Tabela 11 - Estgios de maturidade de arquitetura
Segundo Ross (2006), o objetivo principal da arquitetura empresarial

reconhecer o rumo que a empresa est seguindo. Atravessar os estgios
arquitetnicos permite que as empresas acumulem benefcios.
O processo de gerar esses benefcios envolve muito aprendizado sobre a

direo estratgica da empresa, sobre como a TI contribui com essa direo
e sobre como administrar as capacidades processuais de TI e de negcios
Ross (ROSS, WEILL e ROBERTSON, 2008, p. 73)
2.5 SOA E BPM
O BPM CBOK (ABPMP, INTERNATIONAL, 2009), afirma que para

compreender BPM necessrio definir processo de negcio. Para o CBOK,
processo um conjunto definido de atividades ou comportamentos executados por
humanos ou mquinas para alcanar uma ou mais metas.
No contexto do gerenciamento de processos de negcio, um processo de

negcio definido como um trabalho ponta-a-ponta que entrega valor aos
clientes. [..]
BPM habilitada por tecnologia atravs de ferramentas para modelagem,

simulao, automao, integrao, controle e monitoramento de processos
de negcio e de sistemas de informao que suportam esses processos
(ABPMP, INTERNATIONAL, 2009, p. 30 E 31).
Em 2009, Marc Fiammante (FIAMMANTE, 2009) publicou o Dynamic

SOA and BPM Best Pratices for Business Process Management and SOA Agility
Melhores Prticas para Gerenciamento de Processos e Agilidade SOA. Seu trabalho
inicia com uma anlise de pontos de falha comuns no alcance dos objetivos SOA e
BPM.
Um ponto importante apresentado pelo autor refere-se utilizao de

tecnologias avanadas para simplesmente implementar uma abordagem
cliente/servidor em Web Services. Ele considera que essa abordagem no agrega
valor ao negcio e pode ainda trazer apenas perdas de performance.
Por outro lado, em muitos casos, o BPM tem reintroduzido o rgido

acoplamento de servios de negcio, com uma abordagem desconectada de SOA,
com aplicaes que se limitam a expor funcionalidades j existentes. Segundo
Fiammante (2009), esse modelo falha no objetivo de modularizao e flexibilidade
dos processos de negcio.
Em outros casos, os servios so compreendidos apenas como

operaes, com modelos rgidos de informao sendo utilizados para expor servios
de negcio, sem levar em conta que as estruturas de informao evoluem com o
negcio.
Para Erl, a camada de processos de negcio representa uma parte

bsica de qualquer arquitetura orientada a servios. (ERL, 2009, p. 60)
Josuttis (2008) afirma que em SOA, os servios so tipicamente partes de

um ou mais processos de negcio distribudos. Por isso, a principal motivao para
servios vem de processos de negcio. (JOSUTTIS, 2008, p. 73). Para ele, as
atividades de nveis mais baixas de um processo decomposto, so servios
(JOSUTTIS, 2008, p. 75).
O que se pode concluir que a adoo de uma estratgia de

gerenciamento de processos pode falhar em seus objetivos de automao se no
contar com SOA e que uma implantao SOA consistente, que agregue valor, deve
contar com uma estratgia bem formulada de gesto de processos.
3 ANLISE CRTICA E DESENVOLVIMENTO
Para subsidiar nosso plano de implantao de uma Arquitetura Orientada

a Servios na Cmara dos Deputados, iremos inicialmente contextualizar a empresa,
seu planejamento estratgico, estruturas de governana e arquitetura de TI.
Em seguida, iremos delimitar nosso problema, para melhor elaborar um

plano de implantao de uma arquitetura orientada a servios - SOA.
3.1 CONTEXTO
3.1.1 A estrutura organizacional da Cmara dos Deputados
Para melhor compreenso das estruturas decisrias na Cmara dos

Deputados, iniciaremos como uma breve anlise do seu organograma.
Figura 2- Organograma da Cmara dos Deputados

Fonte: www.camara.gov.br/a-camara/estruturaadm
A Mesa Diretora da Cmara dos Deputados a responsvel pela direo

dos trabalhos legislativos e dos servios administrativos da Casa. Compe-se de
Presidncia, duas Vice-presidncias e quatro Secretarias.
Dentre as atribuies das Secretarias, destacamos, para melhor
embasamento de nosso estudo, as que seguem:
1 Secretaria Superintender os servios administrativos da Cmara (art.

19 do RICD Regimento Interno da Cmara dos
Deputados);
Interpretar e fazer observar o ordenamento jurdico de
pessoal e dos servios administrativos da Cmara (art. 19,
IV, do RICD);
Ratificar despesas da Cmara dos Deputados;
2 Secretaria Providenciar passaporte diplomtico;

Pedir Nota de Visto ao Itamaraty;
Fornecer informaes diversas referentes a passaportes
diplomticos.
3 Secretaria Controlar o fornecimento de requisies de passagens de

transporte areo aos Deputados;
Examinar os requerimentos de licena e justificativa de
faltas.
4 Secretaria Supervisionar o sistema habitacional da Cmara dos

Deputados;
Distribuir as unidades residenciais aos Senhores
Deputados.
Mesa Diretora, subordina-se a Diretoria-Geral, a quem compete

planejar, coordenar, orientar, dirigir e controlar todas as atividades administrativas da
Casa, de acordo com as deliberaes da Mesa Diretora.
A Diretoria Geral se estrutura em duas assessorias: Assessoria Tcnica e

Assessoria de Projetos e Gesto; dois departamentos: Apoio Parlamentar e Polcia
Legislativa e trs diretorias: Legislativa; Recursos Humanos e Administrativa.
A Assessoria de Projetos e Gesto da Diretoria Geral - APROGE atua

com a gesto estratgica da Cmara dos Deputados e como articuladora no plano
multidisciplinar, quando o assunto envolve processos de trabalho e projetos com a
participao de diversos rgos da Casa. Seu principal negcio estimular a
utilizao de metodologias inovadoras e de vanguarda nas diversas reas
relacionadas modernizao organizacional
O Centro de Informtica da Cmara dos Deputados - CENIN est

subordinado Diretoria Administrativa, que responsvel pelo planejamento,
coordenao, orientao e direo das atividades relativas ao oramento, finanas,
contabilidade, comunicao, transporte, servios gerais, obras, manuteno,
material, patrimnio, informtica, segurana, higiene.
3.1.2 Estrutura funcional do Centro de Informtica
O Centro de Informtica foi criado na Resoluo da Resoluo da Cmara

dos Deputados N 16, de 1997. (LEGISLAO - CMARA DOS DEPUTADOS,
2011)
Originalmente, o CENIN foi estruturado em quatro unidades

administrativas:
Servio de Administrao;
Coordenao de Engenharia de Sistemas;
Coordenao de Infraestrutura de Informtica;
Coordenao de Apoio ao Usurio.
Atualmente, o CENIN conta com seis Coordenaes:
Coordenao de Planejamento e Gesto de TIC

Coordenao do Sistema Eletrnico de Votao
Coordenao de Relacionamento com o Cliente
Coordenao de Administrao de Infraestrutura de TIC
Coordenao de Disseminao de Informaes
Coordenao de Engenharia de Sistemas e Anlise de Negcios
Trs entre as seis coordenaes acima, dedicam-se, pelo menos em

parte, ao desenvolvimento de aplicativos para a Organizao. Uma delas, a
Coordenao do Sistema Eletrnico de Votao, dedica-se exclusivamente aos
sistemas relacionados s atividades em Plenrio, como o sistema de votao
eletrnico e presena dos Srs. Parlamentares, entre outros.
A Coordenao de Engenharia de Sistemas e Anlise de Negcios
(CESAN) divide-se ainda em sees responsveis pelos sistemas administrativos,
sistemas legislativos, que incluem os que automatizam o processo legislativo, uma
seo especfica para os sistemas de RH, incluindo a folha de pagamentos, e uma
outra seo responsvel pelo desenvolvimento de solues setoriais.
A Coordenao de Disseminao de Informaes responsvel pelo

Portal Corporativo, alm de outras aplicaes principalmente para a Secretaria de
Comunicao, embora tambm desenvolva algumas solues de sistemas para
outras unidades administrativas.
Cada Coordenao desenvolve aplicaes em seus prprios padres,

frameworks, plataformas e processos de desenvolvimento e essa mesma
diversidade tambm pode ser encontrada no mbito de uma mesma Coordenao.
Existe uma grande quantidade de sistemas legados, desenvolvidos em

plataforma cliente servidor. So sistemas monolticos, focados em processos e
unidades administrativas especficas, com poucas possibilidades de integrao com
outras aplicaes. Muitos desses sistemas j esto ultrapassados e precisam se
adaptar s mudanas nos processos que eles automatizam. Nesse caso alguns
deles so completamente reescritos, como foi o caso da folha de pagamentos, do
sistema de cotas parlamentares, do sistema de eventos, s para citar alguns.
Algumas iniciativas de desenvolvimento de webservices e outros servios

distribudos baseados em COM++ e EJB, tambm esto presentes. No entanto, tais
iniciativas derivam quase que exclusivamente de necessidades de integrao entre
plataformas heterogneas, alm da construo de portais e workflows, mas sem
uma direo clara para um modelo de desenvolvimento baseado em servios. Tais
componentes de servio esto distribudos pela infraestrutura de TI sem qualquer
controle, contrato ou catlogo, possivelmente desempenhando e expondo servios
semelhantes ou redundantes entre si.
Recentemente a CESAN criou uma nova seo, a SECOMP para

organizar um catlogo de componentes e servios, procurando disciplinar e
aperfeioar o acesso a informaes geradas pelos diferentes sistemas.
Importante citar tambm os recentes esforos para o desenvolvimento de

um processo nico de desenvolvimento de software, baseado em metodologias
geis, que tendem a consolidar alguns padres de desenvolvimento que devero ser
seguidos por todas as reas de desenvolvimento de software do Centro de
Informtica da Cmara dos Deputados. No entanto, o processo de desenvolvimento
no trata, como no deveria mesmo tratar, de questes de arquitetura e orientao a
servios e ou processos de negcio, que fazem parte de decises de mais alto nvel.
Algumas reas se mostram muito competentes no desenvolvimento de

solues para reas de negcio especficas. Apresentam alta produtividade, com
solues consistentes e geis. No entanto, tais aplicaes ainda so completamente
isoladas e altamente especializadas.
Diramos que no modelo proposto por Ross (2006) para avaliao do

estgio de maturidade da arquitetura de TI, o CENIN se enquadraria ora no nvel 1,
com a existncia clara de silos de negcio, com dados isolados, ora no nvel 2, onde
algumas estruturas para integrao comeam a ser construdas e j existe uma
infraestrutura comum para suporte s aplicaes - com exceo da coordenao do
sistema eletrnico de votao, que por questes de segurana mantm uma posio
estratgica de relativo isolamento de sua infraestrutura.
A situao atual da Tecnologia da Informao, na Cmara dos Deputados

reflete exatamente os problemas relatados pelos diversos autores pesquisados,
apresentados em nosso referencial terico, no que se refere a um estgio em que as
aplicaes de software esto ainda muito isoladas e focadas no nvel ttico, com
sistemas altamente especializados, um grande acervo de sistemas legados j
ultrapassados que prenunciam grandes e contnuos esforos de reconstruo de
sistemas de automao.
3.1.3 Gesto estratgica e estruturas de governana na Cmara dos

Deputados
A Cmara dos Deputados deu incio Gesto Estratgica em 2004,

quando a Diretoria-Geral promoveu o primeiro ciclo de gesto estratgica. Na
ocasio, foram definidos a misso, os valores e a viso de futuro da rea de apoio
tcnico-administrativo da Casa. Desde ento, foram implantadas metodologias
corporativas de planejamento e de gesto de projetos e de processos (Cmara dos
Deputados).
A Gesto Estratgica da Cmara dos Deputados foi implementada
corporativamente e setorialmente por meio das seguintes instncias:
Comit de Gesto Estratgica - CGE, integrado atualmente pelo Diretor

Geral, pela Secretaria Geral da Mesa (SGM), Diretoria de Recursos
Humanos (DRH) Diretoria Administrativa (DIRAD), Diretoria Legislativa
(DILEG), Secretaria de Comunicao (SECOM), Secretaria de Controle
Interno (SECIN) e Assessoria de Projetos e Gesto (APROGE). o CGE
que detm os direitos decisrios para os projetos de TI, assim como para
os projetos estratgicos como um todo, tendo ainda as seguintes
atribuies:
o Orientar e acompanhar o processo de gesto estratgica da Cmara
dos Deputados.
o Garantir o alinhamento de programas, projetos e processos
estratgicos aos objetivos estratgicos corporativos.
o Acompanhar indicadores de resultado com vistas a avaliar o
cumprimento das metas anuais
Comits Setoriais de Gesto Estratgica - CSG's, formado dentro de cada
unidade administrativa pelo seu titular e chefes a ele diretamente
subordinados, desempenhando, no nvel setorial, no nvel setorial, papel
equivalente ao realizado pelo Comit de Gesto Estratgica no nvel
corporativo;
Escritrio Corporativo de Gesto Estratgica - ECGE, ncleo integrante
da Assessoria de Projetos e Gesto com a funo de assessorar a
Diretoria Geral e o CGE;
Escritrios Setoriais de Gesto Estratgica - ESGE's, ncleos integrantes
de cada unidade administrativa com a funo de assessorar os CSGs.
O Centro de Informtica da Cmara dos Deputados no participa do

Comit de Gesto Estratgica CGE e, portanto, no atua diretamente nas
decises estratgicas da Organizao, participando apenas dos Comits Setoriais
de Gesto Estratgica CSG da Diretoria Administrativa DIRAD.
Para melhor entendimento sobre como os projetos chegam ao Centro de

Informtica e como eles so priorizados, transcrevemos abaixo o modelo atualmente
adotado na Cmara dos Deputados, publicado no Processo de Contas Anual do
Exerccio Financeiro de 2010. (CMARA DOS DEPUTADOS, 2010)
Quanto s demandas por projetos de TIC, o CENIN adotou, com a anuncia

da Diretoria-Geral, um procedimento para racionalizar e dar transparncia
ao processo de priorizao. O processo est representado
simplificadamente na figura a seguir.
Em parceria com os Escritrios de Projetos Setoriais, O CENIN faz ao final

de cada ano o levantamento das demandas candidatas a se tornarem
projetos no planejamento de ao do Centro para o ano seguinte. Identifica
no universo se existem demandas que deveriam ser tratadas em projetos de
TIC corporativos. Os projetos corporativos, chamados internamente de Tipo
A, so aqueles que so originados por imposio normativa, por projetos e
programas estruturantes ou por obsolescncia tecnolgica. Estes projetos
so priorizados pelo Comit de Gesto Estratgica, CGE, por ocasio da
ltima Reunio Avaliao Estratgica do ano. O CGE, composto pelo
Diretor-Geral, Diretor de Recursos Humanos, Diretor Administrativo, Diretor
Legislativo, Secretrio-Geral da Mesa, Secretrio de Controle Interno e
Secretrio de Comunicao Social, tem autonomia para promover e
priorizar outras demandas para Tipo A.
As demais demandas so priorizadas posteriormente no mbito da Diretoria

ou Secretaria de origem, recebendo a classificao de projetos Tipo B,
caso haja disponibilidade de recursos financeiros e humanos no Centro de
Informtica para atend-los.
Finalmente, o CENIN, tendo os projetos do Tipo A e do Tipo B

priorizados, elabora o seu planejamento de ao para o ano seguinte. Neste
planejamento o Centro, considerando a sua capacidade e a priorizao feita
pelas reas clientes, define o conjunto dos projetos que sero iniciados no
ano. Duas premissas so observadas neste planejamento: os projetos do
Tipo A no podem deixar de fazer parte deste e as reas so, na medida
do possvel, atendidas de maneira equilibrada. Como resultado dos critrios
adotados e da capacidade de atendimento do Centro de Informtica,
algumas demandas so sinalizadas que no sero feitas. O planejamento
divulgado para os Escritrios de Projetos Corporativo e Setoriais e para os
membros do CGE.
Caso, ao longo do ano, surja alguma demanda urgente, o procedimento

representado no anexo II disciplina o seu tratamento. Inicialmente, feita
uma avaliao do esforo a ser empreendido com a demanda e do impacto
da incluso dessa demanda nos demais projetos do planejamento.
Como resultado dessa avaliao, elaborado um Relatrio de Impacto
contendo cenrios para adoo da demanda com as suas respectivas
consequncias nos demais projetos da rea. Pode haver cenrio que
indique o atraso em outros projetos ou que outros projetos deixaro de ser
feito para atender a demanda intempestiva. Essa avaliao com os cenrios
so encaminhados ao Patrocinador da demanda postulante a projeto para
que este a apresente junto ao Comit de Gesto Estratgica Corporativa ou
Setorial pertinente. O Comit ento determina se a demanda apresentada
deve ser transformada em projeto e o cenrio escolhido.
3.1.4 Planejamento Estratgico do Centro de Informtica da Cmara dos

Deputados
O Planejamento Estratgico do Centro de Informtica da Cmara dos

Deputados pode nos fornecer alguns indcios para o entendimento do contexto na
organizao e da maturidade empresarial do CENIN.
O Plano Estratgico do CENIN resultado do projeto estratgico Reviso

do Planejamento Plurianual de TIC, que compe o Plano Estratgico 2009-
2012 da Diretoria Administrativa da Cmara dos Deputados. Construdo no
perodo de novembro de 2009 a maio de 2010, ele se alinha com os
objetivos estratgicos contidos no plano corporativo e nos planos setoriais
elaborados pelas diretorias e secretarias da Cmara dos Deputados.
Manifesta, tambm, o comprometimento do Centro com as misses e vises
explicitadas no Plano Estratgico Corporativo e no Plano Estratgico da
DIRAD. (CENIN - PLANEJAMENTO ESTRATGICO, 2010).
A metodologia de planejamento utilizada para a construo do Plano

Estratgico CENIN 2010-2013 foi o Balanced Scorecard (BSC), a mesma adotada
nos demais planos estratgicos elaborados na Cmara dos Deputados.
Seguindo essa metodologia, a estratgia para o atingimento da viso de

futuro do Centro foi representada no Mapa Estratgico do CENIN, que envolve 15
objetivos estratgicos, encaixados em quatro diferentes perspectivas.
As aes na direo do alcance desses objetivos so constitudas por 16

projetos estratgicos, conforme apresentados no Planejamento Estratgico do
CENIN e listados a seguir.
1 Implantao de Estrutura de Desenvolvimento Orientado a Processos

2 Integrao dos diversos processos de desenvolvimento em uso
3 Implantao de processos e ferramentas para Gesto de Servios de TIC-

ITIL
4 Definio de modelo para contratao de servios de TIC e contratao de

servios segundo esse modelo, contemplando as diversas reas:
desenvolvimento, atendimento, suporte tcnico, produo (operao)
5 Programa de Infraestrutura e Servios de TIC
6 Implantao de Soluo de Gesto de Contedos Digitais (ECM)
7 Informaes Gerenciais
8 Portal Corporativo
9 Adequao da estrutura organizacional do CENIN
10 Implantao de processo de Gerencia de Relacionamento
11 Implementao de um Programa de Desenvolvimento de Competncias do

CENIN
12 Definio da Arquitetura de TIC
13 Instituio dos processos de Gesto Estratgica e de Escritrio de Projetos

no CENIN
14 Implantao da Estratgia de Comunicao do CENIN
15 Elaborao de Programa de Melhoria das Condies de Trabalho da equipe

do CENIN
16 Cenrio definitivo para as instalaes fsicas do CENIN
Dentre os projetos acima relacionados, o que trata da implantao de

estrutura de desenvolvimento orientado a processos o primeiro da lista, nos chama
especial ateno, por estar intimamente relacionado com o direcionamento
estratgico para uma gesto de processos.
A Assessoria de Projetos Especiais, APROGE vem estruturando a gesto

de processos na Cmara dos Deputados.
O Processo de Contas Anual do Exerccio Financeiro de 2010, da Cmara
dos Deputados, destaca a Customizao das solues corporativas adquiridas para
a gesto de projetos e processos.
E mais adiante refere-se as aes concretas que esto sendo tomadas

para que se efetivem as prticas de gesto de projetos e processos.
Outra ao fundamental de integrao foi a customizao das solues

corporativas de gesto de projetos MS Project Server e de gesto de
processos IBM WebShere Business Modeler , as quais sero
implantadas em 2011. Essas ferramentas possibilitaro a gesto corporativa
de projetos e processos da Casa, melhorando o compartilhamento de
informaes, o dilogo entre os atores e o acompanhamento dos
resultados. (CMARA DOS DEPUTADOS, 2010)
esperado que, na medida em que os processos forem sendo

compreendidos e modelados, novas demandas para automao desses processos
sero encaminhadas.
Alguns sistemas j esto sendo desenvolvidos com a utilizao de

tecnologias baseadas em orquestradores de processos modelados com notao
BPMN. Tais sistemas esto utilizando componentes de servios, mesmo que de
forma ainda muito incipiente, para tarefas como atualizao de registros em
sistemas de apoio, obteno de dados para encaminhamento e decises de fluxo e
assim por diante.
Josuttis afirma que ao falarmos sobre BPM em relao a SOA, fica claro
que as atividades dos nveis mais baixos de um processo decomposto so
servios. (JOSUTTIS, 2008, p. 74)
Podemos concluir que estratgia de automao de processos via

BPMS, ser necessrio incluir outra de construo de uma arquitetura orientada a
servios para que a primeira possa atingir os seus objetivos de forma efetiva.
3.1.5 Resumo das principais caractersticas de contexto atual do Centro de

Informtica da Cmara dos Deputados
Posio Hierrquica Posicionado no quarto nvel hierrquico da organizao,

subordinado Diretoria Administrativa.
Poderes Decisrios No participa diretamente das decises estratgicas da
organizao, embora fornea subsdios, atravs de uma
relao de demandas encaminhadas ao CENIN pelas
diversas unidades administrativas, que inclui sugestes
de priorizao para o CGE, que o detentor dos direitos
decisrios, em conjunto com a Mesa Diretora.
Planejamento Elabora o seu planejamento estratgico com base nas

Estratgico diretrizes traadas pelo CGE. Seu planejamento
estratgico resulta em um conjunto de projetos
estratgicos, que so acompanhados regularmente pelo
CGE.
Maturidade de Sistemas monolticos desenvolvidos para silos de

Arquitetura negcio especficos.
Integrao, quando presente, ocorre apenas no nvel de

registros de dados.
Mltiplas plataformas de desenvolvimento, no

integradas.
Demandas por evoluo de sistemas legados.
Tecnologias obsoletas.
Componentes de servio desenvolvidos sem registro ou

contrato, dispersos no ambiente de produo.
Pontos de Ateno Projetos de gesto de processos, com indicativo de

futuras demandas de automao.
Sistemas de automao de processos baseados em

BPMS, j em desenvolvimento.
A construo de uma Arquitetura Orientada a Servios - SOA parece ser

um caminho natural para organizaes que j compreendem a necessidade de
melhorar o desenho e automao de seus processos, racionalizar o uso de recursos
de TI e alcanar nveis de produtividade e gerenciamento adequados s
necessidades do negcio.
3.2 PLANO DE PROJETO PARA IMPLANTAO DA SOA
Implantar uma arquitetura orientada a servios, no uma tarefa simples.

Estamos tratando aqui de mudanas culturais importantes, tanto na rea de TI como
nas prprias reas de negcio.
Uma abordagem possvel seria tratar inicialmente as questes de

tecnologia e desenho da arquitetura SOA, como o catlogo de servios, reuso,
granularidade e assim por diante. Tais iniciativas j poderiam conferir ganhos de
produtividade e aproximariam o ambiente tecnolgico de uma viso de componentes
distribudos. Teramos assim a implantao de SOA com uma abordagem de TI, mas
no uma orientao a servios de fato, atingindo apenas um estgio de
componentes distribudos, mas no exatamente orientao a servios.
Numa arquitetura orientada a servios, a tecnologia apoia e integra uma

viso mais abrangente do negcio, que precisa ele mesmo desfragmentar-se,
integrar-se. Por isso, a deciso de implantao dessa arquitetura deve partir do
negcio e no da TI.
Por outro lado, decidir por essa arquitetura sem que a TI esteja
suficientemente madura e instrumentalizada, pode representar um grande risco para
qualquer iniciativa nesse sentido. Ento, partindo do pressuposto de que gesto por
processos e orientao a servios so uma tendncia para as organizaes em
geral e para a Cmara dos Deputados em particular, propomos ao Centro de
Informtica iniciar uma discusso bem fundamentada de SOA, para colaborar e
opinar de forma consistente sobre o tema.
Dessa forma, nossa proposta por um plano de implantao que comea

pelo entendimento da arquitetura no mbito do Centro de Informtica, com
envolvimento das reas estratgicas do negcio. Assim, pretendemos que a
discusso e o entendimento do tema promovam as condies necessrias para a
deciso sobre o melhor momento para a adoo da arquitetura orientada a servios
ou mesmo por no adotar essa arquitetura.
A proposta de implantao de SOA aqui apresentada divide-se em dois
projetos.
O primeiro deles, Entender SOA, tem dois objetivos principais:
a) Dotar os analistas do Centro de Informtica de uma compreenso

consistente e suficiente sobre a arquitetura orientada a servios, suas
vantagens, desvantagens e implicaes.
b) Fornecer s instncias decisrias informaes necessrias e
suficientes para que possam decidir sobre a oportunidade de investir
na implantao da arquitetura.
O segundo projeto refere-se implantao da arquitetura SOA

propriamente dita e s ser executado se e quando a deciso, ao trmino do
primeiro projeto, for pela implantao de SOA.
Uma alternativa ao segundo projeto seria a conduo de outro projeto

com o objetivo de organizar os componentes distribudos que j esto presentes no
ambiente computacional da Cmara dos Deputados. Lembrando que, neste caso,
teremos uma boa organizao de componentes, mas no uma efetiva orientao a
servios.
3.2.1 Projeto 1: Entender SOA
Esse projeto tem como principal objetivo promover o maior envolvimento

possvel de todos os interessados, nivelando conhecimentos em um patamar
adequado de entendimento a respeito do tema, formalizando canais para um debate
amplo e franco e avaliando solues e alternativas de modo a evitar possveis
resistncias e desconfortos que no sejam tcnica ou administrativamente
justificveis.
3.2.1.1 Escopo
3.2.1.1.1 Justificativa
A Arquitetura Orientada a Servios (SOA) um paradigma para

organizao e utilizao de competncias distribudas que esto sob controle de
diferentes domnios proprietrios (MACKENZIE, LASKEY, et al., 2006). Por isso, sua
implantao precisa ser considerada como uma deciso de arquitetura
(Governana).
Josuttis (2008) afirma que antes de iniciar a implantao de SOA crucial

que as instncias decisrias aceitem que SOA uma estratgia, e no uma soluo
pronta. Que compreendam suas possveis consequncias, principalmente no que se
refere ao processamento distribudo.
O autor prope Entender SOA, como primeiro passo para um projeto de

implantao dessa arquitetura. Entender SOA a condio sem a qual no se pode
decidir se a organizao ir ou no investir na mudana.
No que ser refere s questes tecnolgicas, a distribuio das atividades

de desenvolvimento de aplicativos em vrias coordenaes do Centro de Informtica
da Cmara dos Deputados CENIN, pode ser um risco para a deciso por uma
nova arquitetura. Normalmente, tais decises so tomadas, no CENIN, em uma
estrutura de colegiado composto pelo Diretor do Centro e todos os Coordenadores.
E essa no uma estrutura decisria formal para a Organizao, por isso, a
responsabilidade sobre qualquer deciso tomada, no mbito do Centro de
Informtica, do Diretor da rea de TI. muito importante que, na TI, a deciso por
SOA seja tomada com apoio de todo o colegiado, com forte compromisso de todas
as coordenaes envolvidas.
Mas a situao ideal, conforme j apresentamos, que a SOA seja

compreendida como uma questo estratgica e que sua implantao, abstradas as
questes tcnicas, seja uma deciso tomada pelas instncias com poderes e
competncias para tanto.
No campo institucional, questes de adaptao dos desenvolvedores ao

novo paradigma precisam tambm de ateno especial. Decidir por SOA no nvel
estratgico, sem envolver os desenvolvedores e demais interessados, pode
comprometer todo o processo de implantao, tornando a nova arquitetura
ineficiente ou pouco efetiva.
A implantao de SOA ir consumir recursos, que talvez necessitem ser

realocados de outros projetos de TI. importante que as instncias decisrias da
Cmara dos Deputados compreendam as vantagens e desvantagens da opo por
SOA para que possam decidir, de forma consciente, pelos investimentos
necessrios.
Bieberstein (2008) afirma que antes de discutir sobre solues

tecnolgicas e ferramentas, importante olhar para o impacto que uma arquitetura
baseada em SOA ter para a organizao e para as pessoas.
Ao final do projeto, teremos o CENIN nivelado no que se refere aos

principais conceitos de SOA e as instncias decisrias suficientemente informadas
sobre as vantagens, desvantagens, impacto e investimentos necessrios para a
adoo da nova arquitetura.
3.2.1.1.2 Produtos
a) Seminrio sobre Arquitetura Orientada a Servios para o Centro de Informtica;

b) Seminrio sobre Arquitetura Orientada a Servios para a Assessoria de Projetos
da Direo Geral (APROGE), responsvel pelos programas de gesto de
processos e planejamento estratgico da Cmara dos Deputados.
c) Apresentao de piloto construdo com filosofia SOA (CENIN e APROGE);
3.2.1.1.3 Premissas
a) Participao dos coordenadores das reas de desenvolvimento, acompanhados

de pelo menos um analista de sua equipe, em todos os seminrios.
b) Participao de um representante da coordenao de infraestrutura e de um
representante da coordenao de relacionamento com o cliente.
c) Existncia, no quadro de servidores do Centro de Informtica, de profissionais
com conhecimentos e habilidades suficientes para realizar as atividades
previstas no projeto. Caso no haja, ser necessrio formar os analistas antes
de iniciar o projeto.
d) Disponibilidade dos servidores para participao nos seminrios
e) Disponibilidade da equipe do projeto para dedicao ao projeto em tempo
integral.
3.2.1.1.4 Lista de Atividades
Atividade Descrio
Nomear a equipe de projeto Consiste na seleo formal da equipe de projeto,

com suas responsabilidades e disponibilidades para
as tarefas do projeto.
Implantar a infraestrutura do Infraestrutura mnima sugerida: software para
projeto acompanhamento do projeto, ambiente para
armazenamento e versionamento dos documentos
gerados pela equipe, espao para publicao
colaborativa dos documentos gerados, espao
fsico para reunies e seminrios, hardware
compatvel..
Realizar Seminrio para os Elaborao e apresentao do seminrio que ter
analistas de TI por objetivo nivelar a base de conhecimento sobre
SOA, junto ao corpo tcnico do Centro de
Informtica.
Apresentar projeto piloto Apresentao de um projeto de pequeno porte
SOA desenvolvido com base no paradigma SOA
Avaliao dos resultados Sero apresentados dados obtidos por pesquisa
alcanados com o seminrio realizada durante a realizao dos seminrios, com
amplo espao para debates entre os analistas de
TI.
Apresentar resultados para Os resultados do seminrio, projeto piloto e debates
o Comit Gestor do Centro sero apresentados ao Comit Gestor do Centro de
de Informtica Informtica.
Avaliar o projeto e a O Comit Gestor de TI, ir avaliar a oportunidade
oportunidade de mudana de mudana e decidir sobre a continuidade ou
encerramento do projeto.
Realizar Seminrio para a O seminrio para a APROGE dever focar nas
APROGE Assessoria de questes relacionadas a servios como suporte ao
Projetos Especiais da gerenciamento de processos e incluir a.
Diretoria Geral apresentao do Piloto-SOA
Avaliar e decidir Avaliao dos resultados pelas instncias
decisrias e decidir sobre a implantao ou no da
Arquitetura Orientada a Servios.
Encerrar o projeto Encerramento do projeto com avaliao geral e
publicao dos resultados.
3.2.1.1.5 Recursos Humanos
Papel Qtde Perfil
Gerente de Projeto 1 Conhecimento dos conceitos de SOA e arquitetura

JEE. Boa comunicao. Habilidade para
apresentao de conceitos, liderana, organizao.
Analista SOA 1 Profissional com slidos conhecimentos sobre
Arquitetura Orientada a Servios. Habilidades para
comunicao verbal e escrita.
Documentador 1 Profissional com habilidade para elaborao de
apresentaes, grficos e formatao de textos em
ambientes de colaborao.
Analista/Programador 1 Profissional com formao em arquitetura JEE.
JEE Preferncia para detentores de certificao em
arquitetura JEE. Habilidade para anlise e
programao.
3.2.1.1.6 Papis e Responsabilidades
Analista/Programador
Papel
Gerente de Projeto
Documentador
Analista SOA
Tarefa/Atividade JEE
Enumerao e organizao dos AN R CN

conceitos SOA que sero trabalhados
nos seminrios
Elaborao da proposta SOA AN R P CN
Diagramao das apresentaes para AN CN R
os seminrios
Organizao e apresentao dos R P P CN
seminrios e conduo dos debates
Manuteno das pginas de informao AN P R P
e colaborao
Desenvolvimento do projeto piloto AN P R
Legenda: AN Aprovao Necessria CN Contribuio Necessria

R Responsvel P Participao
3.2.1.1.7 Plano de Comunicao
O plano para gerenciamento de comunicao do projeto dever iniciar

pela identificao dos interessados e formatao dos relatrios de acompanhamento
da execuo do cronograma de projeto e resultados dos seminrios, incluindo
demonstrativos de frequncia.
No caso da Cmara dos Deputados, todos os documentos e cronogramas

sero registrados em rea de acompanhamento de projetos j existente, que prov
todos os recursos necessrios para o acompanhamento do projeto.
Os seminrios e discusses devero compor a base de conhecimento do

Centro de Informtica, atualmente instalado em ambiente colaborativo com uso de
uma base Wiki corporativa.
3.2.1.1.8 Plano de Gerenciamento de Riscos
O Gerenciamento de Riscos ser realizado atravs do acompanhamento

da planilha de riscos, onde os principais riscos ao projeto devero ser identificados e
monitorados.
Probabilidade
Classificao
Contingncia
Mitigao
Impacto
Risco
Onde as colunas da tabela representam:
Risco Identificao do risco

Mitigao Aes que visam evitar a materializao do risco
Contingncia Aes que devem ser iniciadas quando o risco se
materializa
Probabilidade Um ndice que indica a probabilidade de
materializao do risco
Impacto Um ndice para o impacto (consequncias
negativas) para o Projeto
Classificao Uma anlise da funo Probabilidade (P) x Impacto
(I), segunda metodologia sugerida pelo PMBOK
(2000) apresentada na matriz de probabilidade e
impacto apresentada abaixo:
Pontuao para riscos especficos
Probabilidade Pontuao do risco = P x I
0,9 0,05 0,09 0,18 0,36 0,72
0,7 0,04 0,07 0,14 0,28 0,56
0,5 0,03 0,05 0,10 0,20 0,40
0,3 0,02 0,03 0,06 0,12 0,24
0,1 0,01 0,01 0,02 0,04 0,08
0,01 0,10 0,20 0,40 0,80
Impacto sobre um objetivo (como custo, tempo ou escopo)
Legenda:
Classificao A - Risco ALTO
Classificao M - Risco MDIO
Classificao B - Risco BAIXO
3.2.2 Projeto 2: Implantar SOA
O segundo projeto refere-se implantao de SOA, propriamente dita e

ser executado caso a mudana para o novo paradigma seja aprovado pelas
instncias decisrias.
3.2.2.1 Escopo
3.2.2.1.1 Justificativa
Aps estudos realizados pela equipe de analistas do Centro de

Informtica em conjunto com os coordenadores das reas de desenvolvimento, a
recomendao do CENIN de adotar a Arquitetura Orientada a Servios SOA, para
orientao dos novos projetos de desenvolvimento de sistemas de automao de
processos, foi aprovada pela Diretoria Geral da Cmara dos Deputados.
Essa nova arquitetura precisa garantir para a rea de TI, que diversos
novos princpios de desenho e arquitetura sejam compreendidos e implementados;
que exista uma infraestrutura capaz de suportar a arquitetura SOA; que existam
mecanismos de gesto suficientes para garantir a efetividade do novo padro e que
sejam mantidas as discusses sobre o tema, de forma a garantir a evoluo
contnua do novo modelo.
Este um projeto de longo prazo, estimado em cerca de trs anos, que

dever prever vrios entregveis durante a sua execuo. Alternativamente,
poder ser dividido em subprojetos, de forma a torna-lo mais facilmente gerencivel.
3.2.2.1.2 Produtos
Centro de Competncia SOA Item 2.2.1 do referencial terico

CCS, implantado
Equipe SOA implantada Item 2.2.2 do referencial terico
Catlogo de Servios Item 2.1.2.1 7 e 2.2.6 do referencial terico

Implantado
Arquitetura SOA ESB Item 1.6 Tabela 3 do referencial terico
implantada
Padres de Desenho da Item 2.1.5 e 2.1.7 do referencial terico
arquitetura SOA adotados
Poltica SOA implantada Item 2.1.5 - tabela 2 e 2.2.3 tabela 8 do referencial
terico
3.2.2.1.3 Premissas
Deciso da Organizao pela implantao da nova arquitetura, o que inclui a

criao do Centro de Excelncia SOA.
Disponibilidade de analistas para formao da equipe SOA que integrar a
equipe do projeto.
Disponibilidade financeira para treinamento dos analistas nas ferramentas que
compem a arquitetura.
Disponibilidade financeira para aquisio e implantao do ESB.
Disponibilidade da equipe do projeto para dedicao ao projeto em tempo
integral.
Compromisso das equipes de desenvolvimento com a nova arquitetura em
implantao.
3.2.2.1.4 Lista de Atividades
Atividade Descrio
Implantar o Centro de O Centro de Competncia SOA CCS o comit,

Competncia SOA ou equipe central responsvel por estabelecer e
governar SOA.
Selecionar e nomear a A equipe SOA ser composta por analistas e
equipe SOA tcnicos do Centro de Informtica responsveis
pela conduo tcnica das atividades de
implantao do projeto, no primeiro momento, e
manuteno das estruturas e documentos tcnicos
ps implantao, atuando como o brao tcnico de
TI para implementao das polticas de
Governana SOA elaboradas pelo CCS e atuando
como suporte para os demais analistas do Centro
de Informtica..
Implantar o catlogo de Construo do catlogo de servios, que poder
servios ser desde um documento mantido em ambiente de
colaborao Wiki, at um banco de dados
especfico para registro do catlogo de servios,
podendo ainda ser integrado ao catlogo do prprio
ESB.
A estrutura e a infraestrutura inicial do catlogo de
servios ser construda segundo deciso de
projeto, considerada a natureza dinmica desse
documento que poder evoluir continuamente,
conforme a arquitetura for alcanando nveis
superiores de maturidade.
A OASIS prope uma arquitetura detalhada para o
catlogo de servios, que precisa ser avaliada
como alternativa de implantao .
Um modelo proposto para o catlogo de servios
apresentado no item 3.2.3.1
Realizar inventrio de Realizar um inventrio de todos os EJB e
servios Webservices desenvolvidos, avaliar a sua incluso
no catlogo de servios.
Implantar o ESB No caso da Cmara dos Deputados, o servidor de
aplicaes JEE homologado j conta com um ESB
instalado, que ser utilizado como infraestrutura
SOA.
A implantao do ESB dever incluir treinamento
para os analistas responsveis.
Elaborar modelo, As diretrizes para a implantao da poltica SOA
infraestrutura e instrues foram descritas no item 2.1.5 da fundamentao
para adoo de terica. Um quadro de exemplo de polticas foi
polticasSOA apresentado na tabela 6 item 2.2.3.
3.2.2.1.5 Recursos Humanos
Os recursos humanos do projeto devero ser alocados diretamente da

equipe SOA que dever ser implantada.
Papel Qtde Perfil
Coordenador do 1 Membro participante das discusses estratgicas

Centro de da Organizao, com slidos conhecimentos do
Competncia SOA - negcio, bom trnsito nas esferas decisrias e
CCS suficientes conhecimentos na rea de TI.
Gerente de Projeto 1 Conhecimento dos conceitos de SOA e arquitetura
JEE. Boa comunicao. Habilidade para
apresentao de conceitos, liderana, organizao.
Analista SOA 2 Analista Snior, com slidos conhecimentos sobre
Arquitetura Orientada a Servios. Habilidades para
comunicao verbal e escrita. Habilidade para
anlise e programao na arquitetura JEE. Bom
conhecimento da Organizao (Cmara dos
Deputados), slidos conhecimentos em anlise e
automao de processos.
Documentador 1 Profissional com habilidade para elaborao de
apresentaes, grficos e formatao de textos em
ambientes de colaborao. Desejvel habilidade
como web designer.
Analista/Programador 2 Profissional com formao em arquitetura JEE.
JEE Preferncia para detentores de certificao em
arquitetura JEE. Habilidade para anlise e
programao na plataforma.
3.2.2.1.6 Papis e Responsabilidades
Analista/Programador
Coordenador do CCS
Papel
Gerente de Projeto
Documentador
Analista SOA
Tarefa/Atividade
JEE
Implantar o CCS R P CN
Selecionar a equipe SOA CN R
Implantar o catlogo de servios AN R CN
Realizar inventrio de servios R CN CN
Implantar o ESB CN AN R CN
Elaborar a poltica SOA AN CN R CN
Legenda: AN Aprovao Necessria CN Contribuio Necessria

R Responsvel P Participao
3.2.2.1.7 Plano de Comunicao
Seguir a mesma abordagem do Projeto I Entender SOA.
3.2.2.1.8 Plano de Gerenciamento de Riscos
Seguir a mesma abordagem do Projeto I Entender SOA.
3.2.3 Consideraes Finais
Alguns pontos chave precisam ser considerados no processo de migrao

para a arquitetura SOA.
3.2.3.1 Visibilidade dos Servios - Catlogo de Servios
O Catlogo de Servios CS , conforme j descrito no referencial

terico, o elemento que confere visibilidade aos servios, relacionando elementos
essenciais como a interface para o servio e o contrato para sua utilizao.
Organizar o CS, principalmente quando h notcia de componentes

dispersos no ambiente de produo, fundamental para que a organizao seja
capaz de racionalizar seus esforos de desenvolvimento, reduzindo o desperdcio e
promovendo o reuso.
Recomendamos que nesses casos, o CS seja imediatamente organizado,

independentemente da efetiva implantao de SOA, embora possamos considerar a
implantao do catlogo de servios como um passo significativo na construo da
base tecnolgica que ir suportar a arquitetura orientada a servios. Ou seja, um
passo na direo de SOA.
A organizao do CS deve incluir a nomeao de estruturas responsveis

pela sua manuteno e polticas suficientes para garantir a visibilidade, a
disponibilidade e a consistncia dos componentes de servio em catalogados.
A OASIS (BROWN, ESTEFAN, et al., 2011) sugere um modelo complexo

e muito bem estruturado para um catlogo de servios. Caso sua completa adoo
no seja possvel, nas etapas iniciais do processo, alguns atributos mnimos devero
ser considerados na implantao de uma primeira verso do CS:
Atributo Descrio
Nome do Servio Exemplo: Deputados
Descrio Uma breve descrio do servio
Propsito Uma descrio detalhada do propsito do servio
Administrador Administrador (gestor) do servio, incluindo informaes
de contato como e-mail e/ou telefone. Informao
relevante para solicitaes de acesso, de alterao, etc.
Responsvel Ncleo responsvel pela implementao, manuteno e
suporte ao servio.
Implementao Modelo de implementao: EJB, webservice, com++
Acesso Instrues para consumo do servio. Forma de acesso.
SLA Nvel de servio acordado para disponibilidade do
servio
Status Em desenvolvimento, em produo, em manuteno,
etc.
Palavras chave Utilizado para mecanismos de busca
Mtodos implementados (descrever para cada mtodo)
Nome do Mtodo Nome que dever ser utilizado para consumo do servio
Descrio Descrio e propsito
Parmetros Parmetros que devero ser fornecidos
Restries Restries de segurana de acesso

Palavras chave Utilizado para mecanismos de busca
Tabela 12 - Atributos para um Catlogo de Servios simplificado
3.2.3.2 ESB Enterprise Service Bus ou Barramento de Servios Corporativos
O ESB considerado como a infraestrutura da arquitetura SOA. Sua

implantao deve ser avaliada com muita ateno pela equipe de TI. Apresenta
grandes vantagens para a arquitetura orientada a servios como facilidade no
consumo e fornecimento de servios, independncia em relao tecnologia em
que o servio foi desenvolvido, segurana aplicada diretamente no barramento,
solicitaes tratadas como filas de servio, evitando problemas comuns no modelo
baseado em transaes distribudas, possibilidade de integrao com o catlogo de
servios, entre outros.
No entanto, no encontramos ainda um padro de referncia para a
implantao do ESB. Sendo assim, cada fornecedor o ir implementar segundo suas
prprias concepes. Isso pode ser um risco para a TI, que pode ser ver dependente
do fornecedor da soluo de ESB. Um risco que dever ser avaliado por cada rea
de TI, com base nas vantagens e desvantagens no uso do barramento.
3.2.3.3 SOA passo a passo
SOA mais do que um framework, um novo paradigma, uma nova

arquitetura. Sua implantao deve ser feita percorrendo estgios sucessivos de
maturidade, para que tanto a TI como a Organizao em geral tenham tempo
suficiente para se adaptar ao novo modelo.
O projeto que denominamos Entender SOA, parte dessa premissa.

Mesmo que a organizao decida por no investir imediatamente na nova
arquitetura, a realizao dos seminrios e debates sobre o tema j representar um
passo importante na compreenso da proposta SOA e trar maior consistncia e
maturidade na deciso de sua implantao imediata, futura ou mesmo o descarte da
proposta SOA.
Conforme descrito no SOA-RAF:
Qualquer sistema de tecnologia criado para fornecer um servio em tal

ambiente referido como uma um sistema baseado em SOA. SOA ,
assim, um paradigma que orienta a identificao, design, implementao
(ou seja, a organizao), e utilizao de tais servios. (BROWN, ESTEFAN,
et al., 2011, p. 21)
Sendo assim, Organizaes, como a Cmara dos Deputados, que j

possuem um acervo considervel de componentes de servios implantados
(webservices, ejb, com++) e inicia projetos de modelagem e automao de
processos, j comeou, na prtica, a ensaiar os primeiros passos na direo de
SOA. Nosso entendimento que uma efetiva implantao da arquitetura agregar
valor a essas iniciativas, com ganhos para toda a organizao.
4 CONCLUSO
Nesse Trabalho de Concluso de Curso, procuramos apresentar um

estudo sobre as principais caractersticas da Arquitetura Orientada a Servios
SOA, com o objetivo de embasar um projeto de implantao dessa arquitetura na
Cmara dos Deputados.
Ao longo de nossa pesquisa, percebemos que essa arquitetura precisa

ser compreendida no como uma questo de tecnologia, mas como uma deciso
estratgica intimamente relacionada com uma viso de gesto por processos
apoiada por servios de negcio.
Implantar SOA um projeto que toca importantes questes culturais. A

arquitetura orientada a servios muda a forma de pensar a empresa que precisar
migrar de uma organizao tradicional hierrquica e estratificada para adotar uma
viso (no necessariamente uma estrutura) integrada por processos e servios de
negcio. No campo das reas de TI, ser necessrio superar a viso de
desenvolvimento de sistemas isolados dedicados a nichos especficos de negcio
para uma nova abordagem de automao de servios e processos.
So mudanas difceis que no deveriam ser adotadas de forma

acelerada, e que poderia no resistir s naturais resistncias que toda mudana
enseja, mas de forma gradual e evolutiva, respeitando as questes culturais que
envolvem as organizaes.
Por isso, procuramos analisar com cuidado a estrutura organizacional da

Cmara dos Deputados, procurando compreender o posicionamento do Centro de
Informtica na organizao e identificar as principais instncias decisrias, sua
forma de atuao e estruturas de apoio, assim como o direcionamento estratgico e
as tendncias j em curso.
No mbito do Centro de Informtica, procuramos compreender como ele

se estrutura e como toma suas decises, de forma a direcionar as discusses sobre
a arquitetura SOA, de forma produtiva e com uma interlocuo efetiva.
Os princpios de desenho e arquitetura SOA foram apresentadas como

forma de garantir o entendimento dos requisitos tecnolgicos necessrios ao suporte
da arquitetura orientada a servios. Isso fundamental para o envolvimento da
equipe de TI no projeto de implantao de SOA. Acreditamos que se a TI no estiver
suficientemente capacitada e instrumentalizada, os esforos de implantao
certamente sero frustrados.
Foram apresentados dois projetos que deveriam orientar a efetiva

implantao da arquitetura. Nossa inteno aqui foi relacionar as tarefas em nvel
bastante alto, uma proposta conceitual. Para a efetiva adoo desses projetos, ser
necessrio decompor essas tarefas para construo de uma EAP mais consistente.
A questo mais significativa a ser considerada na descrio desses

projetos a diviso de dois momentos distintos que so o entendimento da
arquitetura e sua efetiva implantao que ficaria condicionada ao necessrio
posicionamento no mbito das instncias decisrias da organizao.
Uma vez concludos, esses projetos tero iniciado uma migrao para
SOA, dotando a organizao de estruturas e conhecimentos suficientes para que o
ciclo de SOA seja iniciado em uma proposta de evoluo contnua.
Como trabalhos acessrios, que poderiam ser agregados ao projeto,

propomos o estudo de experincias de implantao de SOA em organizaes
pblicas e privadas, procurando identificar possveis riscos ao projeto e tambm uma
pesquisa para avaliao da maturidade SOA na TI e na Organizao.
Como trabalhos futuros, sugerimos uma avaliao dos resultados,

comparando-se o grau de maturidade atual da TI e da Organizao com os estgios
alcanados aps a execuo dos projetos propostos.
5 BIBLIOGRAFIA CONSULTADA
ABPMP, INTERNATIONAL. BPM CBOK - Guia para o Gerenciamento de

Processos de Negcio - Corpo Comum de Conhecimento. Traduo de Jos
Davi Fullan; Mylius Srgio Silva, et al. Chicago: Association of Business Process
Management Professionals, 2009.
BIEBERSTEIN, N. et al. Executing SOA - A Pratical Guide for the Service-

Oriented Architect. 1. ed. Boston: IBM Press, 2008. 213 p. ISBN 978-0-13-235374-
8.
BROWN, P. et al. Reference Architecture Foundation for Service Oriented

Architecture. OASIS - Advancing Open Standards for the Informantion Society,
Julho 2011. Disponivel em: <http://docs.oasis-open.org/soa-rm/soa-
ra/v1.0/csd03/soa-ra-v1.0-csd03.pdf>. Acesso em: Dezembro 2011.
CMARA DOS DEPUTADOS. Processo CD/110.376/2011, 2010. Disponivel em:

<http://www2.camara.gov.br/transparencia/gestao-na-camara-dos-deputados/contas-
da-camara/pasta-administrativa/tomada-de-contas-2010>.
CMARA DOS DEPUTADOS. Estrutura administrativa da Cmara dos Deputados.

Cmara dos Deputados, 2011. Disponivel em: <http://www2.camara.gov.br/a-
camara/estruturaadm>. Acesso em: 2011.
CENIN - PLANEJAMENTO ESTRATGICO. Planejamento Estratgico CENIN -

2010/2013 - Conexo com o Futuro. Centro de Informtica da Cmara dos
Deputados. [S.l.], p. 40. 2010.
ERL, T. SOA Princpios de Design de Servio. Traduo de Carlos Schafranski e

Edson Furmankiewicz. 1. ed. So Paulo: Pearson Prentice Hall, 2009. 320 p. ISBN
978-85-7605-189-3.
FIAMMANTE, M. Dynamic SOA and BPM - Best Practices for Business Process
Management and SOA Agility. 1. ed. Boston: IBM Press, 2009. 192 p. ISBN 978-0-
13-701891-8.
HIGH, R.; KINDER, S.; GRAHAM, S. IBM's SOA Foundation - An Architectural

Introduction and Overview. IBM developerWorks: IBM's resource for developers
and IT professionals, p. 68, Novembro 2005. Disponivel em:
<http://public.dhe.ibm.com/software/dw/webservices/ws-soa-whitepaper.pdf>.
Acesso em: Outubro 2011.
JOSUTTIS, N. M. SOA na Prtica. Traduo de Ivan Bosnic. 1. ed. Rio de Janeiro:

Alta Books, 2008. 265 p. ISBN 978-85-7608-184-5.
KEEN, M. et al. Patterns: Implementing an SOA Using an Enterprise Service Bus.

IBM RedBooks, p. 364, 2004. Disponivel em:
<http://www.redbooks.ibm.com/abstracts/sg246773.html?Open>. Acesso em:
Outubro 2011. Utilizada a verso em PDF.
LEGISLAO - CMARA DOS DEPUTADOS. Legislao. Portal da Cmara dos

Deputados, 2011. Disponivel em: <http://www2.camara.gov.br/atividade-
legislativa/legislacao>.
MACKENZIE, C. et al. Reference Model for Service Oriented Architecture 1.0.

OASIS - Advancing Open Standards for the Informantion Society, 2006.
Disponivel em: <http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf>. Acesso em:
Outubro 2011.
MAIER, M. W.; EMERY, D.; HILLIARD, R. ANSI/IEEE 1471 and Systems

Engineering. IEEE Standard, p. 23, 2000. Disponivel em:
<http://standards.ieee.org/findstds/standard/1471-2000.html>. Acesso em: Outubro
2011.
MLLER, I. et al. A Conceptual Framework for Unified and Comprehensive SOA

Management. Swinburne University of Technology, Hawthorn, Victoria 3122,
Australia, Melbourne, 2009.
ROSS, J. W.; WEILL, P.; ROBERTSON, D. C. Arquitetura de TI como Estratgia

Empresarial. Traduo de Roger Maioli Santos. 1. ed. So Paulo: M. Books do
Brasil Editora Ltda, 2008. 184 p.
STAL, M. Using Architectural Patterns and Blueprints. IEEE - Computer Society.

[S.l.], p. 9. 2006. Volume 23 nmero 2.
WEILL, P.; ROSS, J. W. Governana de TI, Tecnologia da Informao. Como as

empresas com melhor desempenho administram os direitos decisrios de TI
na busca por resultados superiores. Traduo de Roger Maioli Santos. 1. ed.
[S.l.]: M. Books do Brasil Ltda, 2006. 276 p. ISBN 85.89384-0.

Plano Implantacao Pereira PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Plano Implantacao Pereira PDF

Transféré par

Droits d'auteur :

Formats disponibles

Plano de implantao de uma arquitetura orientada

a servios SOA - na Cmara dos Deputados

Antonio Jos de Souza Pereira

Biblioteca Digital da Cmara dos Deputados

"Dissemina os documentos digitais de interesse da atividade legislativa e da sociedade.

Ps-Graduao Pesquisa e Extenso

Especializao em Governana em TI no Setor Pblico

Antonio Jos de Souza Pereira

Plano de implantao de uma arquitetura orientada a

Plano de implantao de uma arquitetura orientada a

Trabalho de concluso de curso

Braslia 02 de janeiro de 2012

Plano de implantao de uma Arquitetura Orientada

Trabalho de concluso de curso

Braslia 2 de janeiro de 2012.

Flvio Feitosa Costa

Centro Universitrio do Distrito Federal

que procuram compreender minha ausncia

durante o longo perodo dedicado s atividades

Agradeo a meus pais, Jos Manoel Pereira e Eliza

de Souza Pereira, pelos fundamentos de carter e

tica to arduamente ensinados e a todos os meus

mestres, que encarnados em professores, amigos e

colegas dos mais diferentes crculos de ao e

convivncia sempre estiveram presentes me

incentivando ao crescimento e aprendizado

um novo comeo, qualquer um pode comear

agora e fazer um novo fim.

Francisco Cndido Xavier.

Palavras chave: SOA. Governana de TI. BPM. Arquitetura Orientada a Servios.

Keywords: SOA. IT Governance. BPM. Service Oriented Architecture. Strategic

ABPMP Association of Business Process Management Professionals

APROGE Assessoria de Projetos e Gesto Estratgica

BPMS Business Process Management System Sistema de Gerenciamento

CBOK BPM Common Body of Knowledge Base de Conhecimento BPM

CCS Centro de Competncia SOA

CENIN Centro de Informtica da Cmara dos Deputados

CIO Chief information officer Chefe de Tecnologia da Informao TI

IEEE IEEE Computer Society Organizao dedicada ao avano da teoria

OASIS Organizao para o Avano de Padres de Informao Estruturada

SOA Services Oriented Architecture Arquitetura Orientada a Servios

Lista de Figuras e Tabelas

Figura 1 - Principais conceitos do Modelo de Referncia.......................................... 32

Figura 2- Organograma da Cmara dos Deputados ................................................. 51

Tabela 1 - Comparativo de princpios de orientao a servios ................................ 30

Tabela 2 - Quadro resumo do Modelo de Referncia SOA ....................................... 34

Tabela 3 - Ingredientes SOA - (JOSUTTIS, 2008) .................................................... 36

Tabela 6- Papis e Responsabilidades propostos por Bieberstein (2006) para

Tabela 7- Exemplo de um formato para formulao de polticasSOA (JOSUTTIS,

Tabela 8 - Vantagens do modelo de desenvolvimento tradicional (ERL, 2009) ........ 45

Tabela 9 - - Desvantagens do desenvolvimento de sistemas tradicional (ERL, 2009)

Tabela 10 - Os quatro nveis arquitetnicos propostos por Ross (2006) ................... 47

Tabela 11 - Estgios de maturidade de arquitetura ................................................... 49

Tabela 12 - Atributos para um Catlogo de Servios simplificado ............................ 75

1.1 Tema ........................................................................................................... 13

1.2 Contexto ....................................................................................................... 15

1.2.1 Gesto por Processos .................................................................................. 16

1.2.2 Criao do Ncleo de Integrao - SECOMP ............................................... 17

1.3 DELIMITAO DO PROBLEMA .................................................................. 17

1.4 Formulao do Problema.............................................................................. 18

1.5 Objetivos ....................................................................................................... 18

1.5.1 Objetivo Geral ............................................................................................... 18

1.5.2 Objetivos Especficos ................................................................................... 18